Re: Update testing policy: how to use Bodhi
On 27/03/10 04:12, Adam Williamson wrote: On Sat, 2010-03-27 at 03:50 +0100, Kevin Kofler wrote: So I don't think blocking an update outright for having received type 2 feedback is sane at all. Sigh. That was why I said not to sidetrack the discussion because it was the least important bit of the post. It was just an example of how easily the policy can be adapted. I'm really not interested in thrashing out the tiny details of *that* in *this* thread, that is not what it's for. I had a whole paragraph about the possibility of an override mechanism for maintainers which I left out precisely in order to avoid this kind of discussion, but apparently that wasn't enough... I'm not sure if your usage policy covers changes to Bodhi, but how about the system emailing the upstream developers (direct and/or email lists) when a release is made available for testing/release and also on any problems found ? Terry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
On Sat, 2010-03-27 at 08:19 +, Terry Barnaby wrote: I'm not sure if your usage policy covers changes to Bodhi, but how about the system emailing the upstream developers (direct and/or email lists) when a release is made available for testing/release and also on any problems found ? That's not really part of this proposal. It's a reasonable feature request for Bodhi, though. You could file it with the Bodhi developers (I think infrastructure trac - https://fedorahosted.org/fedora-infrastructure/ - is the appropriate venue). -- 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: Drop Xorg Nv driver?
On Sat, Mar 27, 2010 at 05:36:29AM +0530, Rahul Sundaram wrote: Hi, Nvidia has announced that they are deprecating it http://lists.freedesktop.org/archives/xorg/2010-March/049749.html They are recommending users to use Vesa instead as the replacement but the real reason appears to be Nouveau which Fedora has supported for a long time now. Has to be said that I've always had better luck with nv. Nouveau has seemed to be very unstable to me (although it's always been hard to pin down actual reproducible bugs). I never used and don't care about any 3D or advanced features though ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CVE-2009-2904 - not patched F11 openssh?
On Friday 26 March 2010 07:25:53 pm Michał Piotrowski wrote: Vulnerability described in CVE-2009-2904 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2904 was addressed in https://rhn.redhat.com/errata/RHSA-2009-1470.html for RHEL. Isn't F11 openssh version also vulnerable? RHEL5 uses version 4.3. The CVE was caused by a flaw in a patch that backported a feature from 4.8 to 4.3. Fedora 11 is on 5.2, so it should not be vulnerable. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ruby-tcltk totally broken and obsolete since ages?
Hi, there have been serious bugs filled and ignored against this package for ages, see eg https://bugzilla.redhat.com/show_bug.cgi?id=483537 https://bugzilla.redhat.com/show_bug.cgi?id=560053 Perhaps the maintainers did not realise the severity of the bugs - it appears that any nontrivial example will inevitably crash. I have tried to debug with gdb valgrind, all I can say it is non quite trivial, seems like some memory management garbage collection issue. The last version that ever worked for me was in Red Hat Linux release 8.0 (Psyche), I have skipped a few intermediate releases before jumping on Fedora so no idea when exactly it stopped working. I have recompiled and installed the ruby and tcltk packages from this source. The finding is that programs that worked in RH 8 crash in F10 F12 even when exact the same sources are used. Possibly ruby or tcltk relied on some assumptions that does not work with newer glibc. I hope that someone has an idea - otherwise I think it is safe to completely remove the package. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100327 changes
Compose started at Sat Mar 27 08:15:07 UTC 2010 Broken deps for i386 -- anaconda-14.2-1.fc14.i686 requires fcoe-utils = 0:1.0.12-2.20100323git edje-0.9.93.063-1.fc14.i686 requires libembryo-ver-svn-05.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_job.so.0 emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_fb.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_x.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_txt.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_job.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_con.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedbus.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libehal.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_fb.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_x.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_ipc.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedje.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_file.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet_mime.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libedje.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 ewl-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet.so.0 ewl-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet_mime.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_evas.so.0 ghc-haskell-platform-2009.3.1.20100115-0.2.fc13.i686 requires ghc-HTTP = 0:4000.0.8 ghc-haskell-platform-2009.3.1.20100115-0.2.fc13.i686 requires ghc-network = 0:2.2.1.5 ghc-haskell-platform-2009.3.1.20100115-0.2.fc13.i686 requires ghc-QuickCheck = 0:2.1.0.2 ghc-haskell-platform-2009.3.1.20100115-0.2.fc13.i686 requires ghc-cgi = 0:3001.1.7.1 ghc-haskell-platform-devel-2009.3.1.20100115-0.2.fc13.i686 requires ghc-QuickCheck-devel = 0:2.1.0.2 ghc-haskell-platform-devel-2009.3.1.20100115-0.2.fc13.i686 requires ghc-cgi-devel = 0:3001.1.7.1 ghc-haskell-platform-devel-2009.3.1.20100115-0.2.fc13.i686 requires ghc-HTTP-devel = 0:4000.0.8 ghc-haskell-platform-devel-2009.3.1.20100115-0.2.fc13.i686 requires ghc-network-devel = 0:2.2.1.5 ghc-haskell-platform-doc-2009.3.1.20100115-0.2.fc13.i686 requires ghc-QuickCheck-doc = 0:2.1.0.2 ghc-haskell-platform-doc-2009.3.1.20100115-0.2.fc13.i686 requires ghc-HTTP-doc = 0:4000.0.8 ghc-haskell-platform-doc-2009.3.1.20100115-0.2.fc13.i686 requires
Re: Update testing policy: how to use Bodhi
Terry Barnaby ter...@beam.ltd.uk writes: I'm not sure if your usage policy covers changes to Bodhi, but how about the system emailing the upstream developers (direct and/or email lists) when a release is made available for testing/release and also on any problems found ? As an upstream developer, I can hardly think of a quicker way to piss me off than if every distro were to start sending me such nagmail. I would not want such a thing turned on on *any* of my packages. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
On Sat, 2010-03-27 at 08:19 +, Terry Barnaby wrote: I'm not sure if your usage policy covers changes to Bodhi, but how about the system emailing the upstream developers (direct and/or email lists) when a release is made available for testing/release and also on any problems found ? I would be _very_ careful with sending autogenerated spam to random people that have not signed up for it. I would expect many people to react negatively to it. Sending a small note along the lines of 'Hey, I'm packaging your software for Fedora. How about you mention on the website that it is not only available in Ubuntu but also in Fedora' is a quite different thing, and should be done. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update testing policy: how to use Bodhi
On Fri, Mar 26, 2010 at 03:49:28PM -0700, Adam Williamson wrote: 1. I have tried this update in my regular day-to-day use and seen no regressions. 2. I have tried this update in my regular day-to-day use and seen a regression: bug #XX. 3. (Where the update claims to fix bug #XX) I have tried this update and found that it does fix bug #XX. 4. (Where the update claims to fix bug #XX) I have tried this update and found that it does not fix bug #XX. 5. I have performed the following planned testing on the update: (link to test case / test plan) and it passes. 6. I have performed the following planned testing on the update: (link to test case / test plan) and it fails: bug #XX. I have some additions: 7. fixes bug X, but does not claim to fix it This can often happen with hardware related bugs, e.g. with the kernel where something starts to work again 8. The package updated sucessfully, but was not used intentionally. No breakage noticed. This shows, that at least on the test machine, there are no broken deps, conflicts or broken scriptlets. Also it would be nice to provide hardware testing feedback, e.g. for Xorg updates to say Works with nouveau, Geforce XY, using VGA out and XV, which then shows that e.g. 3D support, DVI out or multi screen support was not tested. This is kind of related to testing with a test plan, but having this data available in a format that can be easily parsed, would be nice, too. Maybe this could be done with adding smolt information in the feedback and the tested features (XV, VGA, DVI, 3D, ...) and the update needs to have some meta data, which kind of devices are supported (e.g. only Geforce devices for the nouveau driver package). Regards Till pgpHcRSV60m0K.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning greyhounds package
On Sat, Mar 13, 2010 at 15:51:37 -0700, Kevin Fenzi ke...@scrye.com wrote: - If currently crashes due to poor coding: https://bugzilla.redhat.com/show_bug.cgi?id=562038 (basically trying to reload a saved game makes it crash). I found an off by one error (typical the last element of the array's index is one less than the size of the array, not the size of the array). It only crashes when compiled with fortify options. I don't think the correct value was being saved in the first place. I expect to have test builds up shortly and will update the bug at that time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: No Build ID error when building new OpenVZ kernel in FEDORA8
xinglin wrote: Hi, I am Xing, a PHD candidate in University of Utah. I am trying to compile and install an OpenVZ kernel in FEDORA8, but one error prevents me. The error is No build ID note found in /var/tmp/kernel***. I have tried several ways to solve it but still failed. I introduced what I did to solve this problem and hope to get some help from you. Hello Xing! I know nothing about OpenVZ and only a little about compiling Linux, but I thought I'd point out that Fedora 8 was retired over a year ago. No bugs will get fixed in Fedora 8 anymore, so it's pretty much off-topic on this list. I would suggest trying with Fedora 12 instead. I think you're more likely to get replies if you can reproduce the problem on a current version of Fedora. ~/openvz/ovzkernel-2.6.18-128.2.1.el5.028stab064.7.src.rpm I see el5 in there. Have you tried compiling it on RHEL 5 or CentOS 5? Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100327 changes
Compose started at Sat Mar 27 09:15:06 UTC 2010 Broken deps for i386 -- gnome-web-photo-0.9-4.fc13.i686 requires gecko-libs = 0:1.9.2.1 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 libnodeupdown-backend-openib-1.9-5.fc13.i686 requires libosmcomp.so.3(OSMCOMP_2.3) libnodeupdown-backend-openib-1.9-5.fc13.i686 requires libosmcomp.so.3 moblin-app-installer-0.4.0-0.7.fc13.i686 requires libpackagekit-glib2.so.13 pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 sepostgresql-8.4.2-2488.fc13.i686 requires postgresql-server = 0:8.4.2 totem-youtube-2.29.92-1.fc13.i686 requires libgdata.so.7 zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 Broken deps for x86_64 -- gnome-web-photo-0.9-4.fc13.x86_64 requires gecko-libs = 0:1.9.2.1 hornsey-1.5.2-0.1.fc13.x86_64 requires libclutter-gst-0.10.so.0()(64bit) libnodeupdown-backend-openib-1.9-5.fc13.x86_64 requires libosmcomp.so.3(OSMCOMP_2.3)(64bit) libnodeupdown-backend-openib-1.9-5.fc13.x86_64 requires libosmcomp.so.3()(64bit) moblin-app-installer-0.4.0-0.7.fc13.x86_64 requires libpackagekit-glib2.so.13()(64bit) pyclutter-gst-0.9.2-1.fc12.x86_64 requires libclutter-gst-0.10.so.0()(64bit) sepostgresql-8.4.2-2488.fc13.x86_64 requires postgresql-server = 0:8.4.2 totem-youtube-2.29.92-1.fc13.x86_64 requires libgdata.so.7()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 New package bakefile A cross-platform, cross-compiler native makefiles generator New package cppi C preprocessor directive indenter New package perl-Net-STOMP-Client STOMP object oriented client module New package pidgin-birthday-reminder Birthday Reminder plugin for Pidgin New package python-empy A powerful and robust template system for Python New package skf Utility binary files in Simple Kanji Filter Updated Packages: PackageKit-0.6.3-0.1.20100322git.fc13 - * Tue Mar 23 2010 Richard Hughes rhug...@redhat.com - 0.6.3-0.1.20100322git - Add a pre-release snapshot to include all of the most recent fixes for the F13 beta release. - Remove preupgrade hard depends as it's not installed by default for gnome-desktop in comps. * Mon Mar 22 2010 Rex Dieter rdie...@fedoraproject.org - 0.6.2-2 - -qt: add minimal qt4 runtime dependency (#573308) * Mon Mar 15 2010 Richard Hughes rhug...@redhat.com - 0.6.2-1 - New upstream release of 0.6.2. - Update to the latest version of the Fedora Packaging Guidelines - Do not Require: pkgconfig - Fix up a few file ownership issues - Remove the custom BuildRoot - Do not clean the buildroot before install anaconda-13.37-1.fc13 - * Thu Mar 25 2010 David Lehman dleh...@redhat.com - 13.37-1 - Unlock the CD tray door in isys.ejectcdrom() (#569377) (pjones) - Texts under storage/formats missing from the .pot file (#576082). (akozumpl) - Translate the Back button in glade (#576082) (akozumpl) - Add originalFormat handling to editLVMLogicalVolume. (#576529) (dlehman) - Fix a cutpaste error that caused a traceback (#574743) (dlehman) - yum requires the proxy settings to include a protocol (#576691). (clumens) - Only look for extended partitions on partitioned devices (#576628) (hdegoede) - Fix referring to disks by-label, by-uuid, etc (#575855). (clumens) - Fix syntax for passing a mapping to a translatable string (#576085). (clumens) - Catch NotImplementedError when scanning for disklabels (#566722) (hdegoede) - Filter UI do not start / stop BIOS RAID sets to get there size (#574587) (hdegoede) - Make filter UI honor nodmraid cmdline option (#574684) (hdegoede) - Properly align the first partition we create (#574220) (hdegoede) - Update filter for translation log entries. (dlehman) * Mon Mar 22 2010 David Lehman dleh...@redhat.com - 13.36-1 - Don't pass size=1 for autopart PVs. Use PartitionDevice's default size. (dlehman) - Make python start with correct default unicode encoding (#539904). (akozumpl) - Fixes bug #569373 - Change udev_trigger block calls to use change action (bcl) - Fix: execWithRedirect() unexpectedkeyword argument 'searchPath' (#572853) (hdegoede) - Do not crash on .autorelabel when using read only rescue mount (#568367) (msivak) - Do not crash when getDevices returns NULL (#567939) (msivak) gnome-packagekit-2.29.92-0.1.20100315git.fc13 - * Mon Mar 15 2010 Richard Hughes rhug...@redhat.com - 2.29.92-0.1.20100315git - New snapshot from the master branch - Rebuild against the latest PackageKit - Should fix the silent failure when the simulate depsolve fails - Ensure that there can only eve be one update icon running in a session. kdeutils-4.4.1-2.fc13
Maximum length of userid on Fedora Linux
Hallo, I want to ask which is the maximum length of a userid on Fedora Linux. I think the maximum length of a userid should be 16 but I want to get a confiration about this assumetion. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Maximum length of userid on Fedora Linux
On Saturday 27 March 2010 10:12:32 am Jochen Schmitt wrote: Hallo, I want to ask which is the maximum length of a userid on Fedora Linux. I think the maximum length of a userid should be 16 but I want to get a confiration about this assumetion. $ sudo useradd a23456789012345678901234567890 $ ls /home/a23456789012345678901234567890/ ls: cannot open directory /home/a23456789012345678901234567890/: Permission denied I think there isn't a 16 char limit ;). Regards, -- Conrad Meyer ceme...@u.washington.edu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: No Build ID error when building new OpenVZ kernel in FEDORA8
On 3/27/2010 12:19, xinglin wrote: The fact is Emulab does not have Fedora12 now. We just have Fedora8 and Fedora10. :( I will talk with the Emulab administrators about this. If the lab can't keep up with updates to Fedora releases it should seriously try going with a distribution with longer term support, such as CentOS. Fedora 8 lost support over a year ago, and RH 9 lost support almost six years ago. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: No Build ID error when building new OpenVZ kernel in FEDORA8
On Sat, 27 Mar 2010 12:27:45 -0500, Garrett Holmstrom gho...@fedoraproject.org wrote: On 3/27/2010 12:19, xinglin wrote: The fact is Emulab does not have Fedora12 now. We just have Fedora8 and Fedora10. :( I will talk with the Emulab administrators about this. If the lab can't keep up with updates to Fedora releases it should seriously try going with a distribution with longer term support, such as CentOS. Fedora 8 lost support over a year ago, and RH 9 lost support almost six years ago. Get it. Thanks for this information. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CVE-2009-2904 - not patched F11 openssh?
2010/3/27 Steve Grubb sgr...@redhat.com: On Saturday 27 March 2010 09:17:55 am Steve Grubb wrote: On Friday 26 March 2010 07:25:53 pm Michał Piotrowski wrote: Vulnerability described in CVE-2009-2904 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2904 was addressed in https://rhn.redhat.com/errata/RHSA-2009-1470.html for RHEL. Isn't F11 openssh version also vulnerable? RHEL5 uses version 4.3. The CVE was caused by a flaw in a patch that backported a feature from 4.8 to 4.3. Fedora 11 is on 5.2, so it should not be vulnerable. More research...looks like this took care of it: * Mon Sep 21 2009 Jan F. Chadima jchad...@redhat.com - 5.2p1-6 - remove homechroot patch So if you are on 5.2p1-6, you should be OK. This upgrade should be pushed to updates-testing and updates yum --enablerepo=updates-testing upgrade openssh [..] openssh x86_64 5.2p1-5.fc11 updates-testing 265 k Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning DR17 and EFL
Am Dienstag, den 16.03.2010, 22:11 +0100 schrieb Thomas Janssen: Hi, As-Salāmu `Alaykum im orphaning: e_dbus ecore edje eet efreet embryo emotion epeg epsilon evas ewl libeina and I will also orphan enlightenment. Reason: The problem started with my co-maintainer cassmodiah, building embryo .063 release for F-13 without waiting for me to have the complete chain built at least locally and having it tested. That's the way i do my packaging stuff. Nothing terribly bad so far, he just wanted to help me. Sorry for this, but this should be fixable. I haven't understand why you made such a trouble for this silly mistake I made...!? While i was fiddling with some DSO problem i had some talk with upstream. Upstream recommended to me to deprecate some packages since they aren't supported anymore, but change the chain to their DR17 and EFL release 1.0 that's soon coming up. http://trac.enlightenment.org/e/wiki/Packaging I was waiting for that release to get it eventually into F-13. At some point, a few days ago, i decided that i can't wait for it for F-13 and was thinking about using epoch to downgrade embryo again. Thankfully, cwickert made the point that i could ask rel-eng to get this build untaged. I made a ticket for it with rel-eng and had another one to do with FESCo since rel-eng couldn't do it on it's own. Both rel-eng and FESCo did a perfect job there and decided the right thing for the enduser to get it untaged. Thank you very much again. The real reason to get the packages orphaned is the continued annoyance of cwickert on IRC (#fedora-de), trying to force me into the role of the bad guy there, since he did not understand the problem, even not in the FESCo Meeting from today. See the FESCo ticket to get a hint of what was going on in #fedora-de. https://fedorahosted.org/fesco/ticket/355 Trying to force anybody into pushing an untested release into F-13. You can see that even in the Meeting log. Instead of let me do my job as package maintainer. So i'm really sick and tired and give it away. Coming back to that social problem mentioned. The rel-eng ticket was clearly mentioned in #fedora-de and even to cassmodiah (if i have to upload backlogs, cassmodiah == boelkmoeller3), not just by me, but as well by cwickert. Everything was talked about, as well what i want to do. The only social problem here was an arrogant and stubborn cwickert. Sorry, but i can't stand a liar. Sorry, but I don't understand this. Christoph is my best friend in the Fedora Project. He is sometimes a little bit stubborn and sometimes a arrogant guy, but he is always fair and he has a open ear for everyone and every problem and he always gives his best to deal justly. He's like a modern Salomo and if you have a problem with Christoph, you should discuss this with him directly, or add him to your ignore list for continueing a noisefree maintaining of your stuff. Imho the fact that you have a personal problem with anybody in the project isn't a good reason for orphaning packages. It's your decision and I don't want to disabuse you, but you turn down any help (Rudof Kastl known as Che and Christoph Wickert and Sven Lankes, knwown as killefiz offers you help) and you are not able to take crtism. Maybe this is the real reason for this problem?! Don't take anything (which is spoken to you) personally, it's just business. If someone want to grab the packages, feel free. Nobody wants this packages? Sad! I can't maintain the whole enlightenment tree alone , because I haven't enough time and knowledge base to handle this, although some friends offers me help to fix this. I would take these packages again if there is a bunch of people who tried to help me permanently, but I'm pessimistic of this. :-( It's very sad, because enlightenment is a cool desktop and a real alternative to other windowmanagers like the ugly openbox. LXDE for example works with enlightenment and it's very cool to have a desktop that gives you such a style without being a fat bitch :-p (Sorry Christoph, but you already know my opinion) -- LG Thomas Dubium sapientiae initium -- Mit freundlichen Grüßen aus dem schönen Hainzell Simon Wesp http://www.fedoraproject.org/wiki/SimonWesp signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Maximum length of userid on Fedora Linux
Jochen Schmitt píše v So 27. 03. 2010 v 18:12 +0100: I want to ask which is the maximum length of a userid on Fedora Linux. (UT_NAMESIZE - 1). UT_NAMESIZE is defined in utmp.h I think the maximum length of a userid should be 16 but I want to get a confiration about this assumetion. What's special about 16? Why not 8, 15, 17, 24, 32? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Text-MultiMarkdown/devel .cvsignore, 1.3, 1.4 perl-Text-MultiMarkdown.spec, 1.2, 1.3 sources, 1.3, 1.4
Author: iarnell
Update of /cvs/pkgs/rpms/perl-Text-MultiMarkdown/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv4973
Modified Files:
.cvsignore perl-Text-MultiMarkdown.spec sources
Log Message:
* Sat Mar 27 2010 Iain Arnell iarn...@gmail.com 1.33-1
- update to latest upstream version
- use perl_default_filter and DESTDIR
- add MultiMarkdown script to files
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Text-MultiMarkdown/devel/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 22 Jan 2010 04:54:18 - 1.3
+++ .cvsignore 27 Mar 2010 06:16:51 - 1.4
@@ -1 +1 @@
-Text-MultiMarkdown-1.32.tar.gz
+Text-MultiMarkdown-1.33.tar.gz
Index: perl-Text-MultiMarkdown.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Text-MultiMarkdown/devel/perl-Text-MultiMarkdown.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- perl-Text-MultiMarkdown.spec22 Jan 2010 04:54:18 - 1.2
+++ perl-Text-MultiMarkdown.spec27 Mar 2010 06:16:51 - 1.3
@@ -1,5 +1,5 @@
Name: perl-Text-MultiMarkdown
-Version:1.32
+Version:1.33
Release:1%{?dist}
Summary:Convert MultiMarkdown syntax to (X)HTML
License:BSD
@@ -21,6 +21,8 @@ BuildRequires: perl(Text::Markdown) =
Requires: perl(Text::Markdown) = 1.26
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+%{?perl_default_filter}
+
%description
Markdown is a text-to-HTML filter; it translates an easy-to-read / easy-to-
write structured text format into HTML. Markdown's text format is most
@@ -37,7 +39,7 @@ make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
@@ -54,9 +56,16 @@ rm -rf $RPM_BUILD_ROOT
%defattr(-,root,root,-)
%doc Changes License.text MANIFEST.skip README Readme.text Todo
%{perl_vendorlib}/*
+%{_bindir}/*
+%{_mandir}/man1/*
%{_mandir}/man3/*
%changelog
+* Sat Mar 27 2010 Iain Arnell iarn...@gmail.com 1.33-1
+- update to latest upstream version
+- use perl_default_filter and DESTDIR
+- add MultiMarkdown script to files
+
* Fri Jan 22 2010 Iain Arnell iarn...@gmail.com 1.32-1
- update to latest upstream
- remove BR perl(File::Slurp)
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Text-MultiMarkdown/devel/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 22 Jan 2010 04:54:18 - 1.3
+++ sources 27 Mar 2010 06:16:51 - 1.4
@@ -1 +1 @@
-aae27ec056cf9bc3ab6a922bcf27ace3 Text-MultiMarkdown-1.32.tar.gz
+ae2f473762803a8593d2bdd2ebec77a5 Text-MultiMarkdown-1.33.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-parent/devel perl-parent.spec,1.6,1.7
Author: iarnell
Update of /cvs/pkgs/rpms/perl-parent/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv8938
Modified Files:
perl-parent.spec
Log Message:
* Sat Mar 27 2010 Iain Arnell iarn...@gmail.com 1:0.223-3
- dual-life module
- add epoch to match that of parent in core
- use core macros, not vendor
Index: perl-parent.spec
===
RCS file: /cvs/pkgs/rpms/perl-parent/devel/perl-parent.spec,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -p -r1.6 -r1.7
--- perl-parent.spec7 Dec 2009 15:20:56 - 1.6
+++ perl-parent.spec27 Mar 2010 06:58:31 - 1.7
@@ -1,6 +1,7 @@
Name: perl-parent
+Epoch: 1
Version:0.223
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Establish an ISA relationship with base classes at compile time
License:GPL+ or Artistic
Group: Development/Libraries
@@ -36,7 +37,7 @@ find . -type f -exec chmod -c -x {} +
# sed -e '/perl([DFR].*)/d'
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+%{__perl} Makefile.PL INSTALLDIRS=perl
make %{?_smp_mflags}
%install
@@ -58,10 +59,15 @@ rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes t/
-%{perl_vendorlib}/*
+%{perl_privlib}/*
%{_mandir}/man3/*
%changelog
+* Sat Mar 27 2010 Iain Arnell iarn...@gmail.com 1:0.223-3
+- dual-life module
+- add epoch to match that of parent in core
+- use core macros, not vendor
+
* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 0.223-2
- rebuild against perl 5.10.1
--
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-parent/F-13 perl-parent.spec,1.6,1.7
Author: iarnell
Update of /cvs/pkgs/rpms/perl-parent/F-13
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv9131
Modified Files:
perl-parent.spec
Log Message:
* Sat Mar 27 2010 Iain Arnell iarn...@gmail.com 1:0.223-3
- dual-life module
- add epoch to match that of parent in core
- use core macros, not vendor
Index: perl-parent.spec
===
RCS file: /cvs/pkgs/rpms/perl-parent/F-13/perl-parent.spec,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -p -r1.6 -r1.7
--- perl-parent.spec7 Dec 2009 15:20:56 - 1.6
+++ perl-parent.spec27 Mar 2010 06:59:39 - 1.7
@@ -1,6 +1,7 @@
Name: perl-parent
+Epoch: 1
Version:0.223
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Establish an ISA relationship with base classes at compile time
License:GPL+ or Artistic
Group: Development/Libraries
@@ -36,7 +37,7 @@ find . -type f -exec chmod -c -x {} +
# sed -e '/perl([DFR].*)/d'
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+%{__perl} Makefile.PL INSTALLDIRS=perl
make %{?_smp_mflags}
%install
@@ -58,10 +59,15 @@ rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes t/
-%{perl_vendorlib}/*
+%{perl_privlib}/*
%{_mandir}/man3/*
%changelog
+* Sat Mar 27 2010 Iain Arnell iarn...@gmail.com 1:0.223-3
+- dual-life module
+- add epoch to match that of parent in core
+- use core macros, not vendor
+
* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 0.223-2
- rebuild against perl 5.10.1
--
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 Catalyst-View-Email-0.27.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Catalyst-View-Email: 963b505c849d835e12428460ab61c232 Catalyst-View-Email-0.27.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 with Fedora 12 + updates-testing - 2010-03-27
The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: perl-CGI-Application-Plugin-DBIProfile-0.07-1.fc12.noarch from fedora-updates-testing-12-i386 unresolved deps: perl(HTML::BarGraph) perl(SVG::TT::Graph::Bar) package: perl-CGI-Application-Plugin-DBIProfile-0.07-1.fc12.noarch from fedora-updates-testing-12-ppc unresolved deps: perl(HTML::BarGraph) perl(SVG::TT::Graph::Bar) package: perl-CGI-Application-Plugin-DBIProfile-0.07-1.fc12.noarch from fedora-updates-testing-12-ppc64 unresolved deps: perl(HTML::BarGraph) perl(SVG::TT::Graph::Bar) package: perl-CGI-Application-Plugin-DBIProfile-0.07-1.fc12.noarch from fedora-updates-testing-12-x86_64 unresolved deps: perl(HTML::BarGraph) perl(SVG::TT::Graph::Bar) -- 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
