devel March 2010

devel@lists.fedoraproject.org

284 participants
338 discussions

FWD: orphaning curlftpfs , mod_auth_shadow
by Kevin Fenzi 20 Apr '10

20 Apr '10

I'm forwarding this for David Anderson: From: David Anderson <fedora-packaging(a)dw-perspective.org.uk> To: fedora-devel-list(a)redhat.com Subject: Orphaning curlftpfs , mod_auth_shadow Date: Mon, 11 Jan 2010 11:22:25 +0000 User-Agent: KMail/1.12.4 (Linux/2.6.31.6-166.fc12.x86_64; KDE/4.3.4; x86_64; ;) Greetings, Due to a slow African Internet connection and ever-growing responsibilities, I regret that I have to and am orphanning these two packages: curlftpfs - mount FTP filesystems via FUSE and curl mod_auth_shadow - Apache authentication via /etc/shadow There are a couple of open bugs for curlftpfs which I said I'd fix by upgrading to the latest version, but it's so long since I used the system and I'm battling with the accounts system, expired certificates. Both these packages I originally packaged because I wanted to use them. I'd have thought that they'd both have many users. Many thanks, David

4 3

License change: swarp
by Sergio Pascual 19 Apr '10

19 Apr '10

Hi all: the new version of swarp in rawhide (2.17.6) will have a CeCILL license. Previously, swarp was distributed under GPLv2 Regards

2 3

intent to retire: kudzu
by Bill Nottingham 18 Apr '10

18 Apr '10

I'd like to retire kudzu for F-13. Why? - There are places where it almost certainly does not work with current kernels - It's so deprecated that one of its replacements (HAL) has since been frozen and deprecated - Given that, its upstream is very dead However, it is still being required by two programs: - hwbrowser - fwfstab If someone wants to keep it limping along for thsese two programs I can orphan it. But I'd really rather just retire it. Bill

11 17

What are the rules for which package we build against in F-13?
by Richard W.M. Jones 08 Apr '10

08 Apr '10

So I submitted a rebuild for libguestfs in F-13 (just now). This was built against: plymouth-core-libs 0.8.0-0.20100114.2.fc13 But the version of plymouth that I get when I install plymouth from F-13 updates-testing on a local machine (after 'yum --enablerepo=\* clean all') is: plymouth-core-libs 0.8.0-0.20100225.1.fc13 and neither of those versions is mentioned by Bodhi. Bodhi seems to suggest that it should be building against and using another version entirely: https://admin.fedoraproject.org/updates/search/plymouth plymouth-0.8.0-0.20100305.1.fc13 I'm confused by this situation ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html

6 12

RPM packaging workshop example
by Rahul Sundaram 07 Apr '10

07 Apr '10

Hi, For the purpose of doing a RPM packaging workshop, I need a simple clear hello world type example using autotools. Can anyone point me to something suitable for the purpose? Rahul

5 9

Upstream bugs vs. Fedora bugs: KDE people do it wrong
by Christoph Wickert 06 Apr '10

06 Apr '10

I am irritated by the way the KDE SIG and the KDE bugzappers handle bugs. For most bugs that are reported they demand the reporter to file an upstream bug report at bugs.kde.org and set the bug to NEEDINFO. If the reporter doesn't respond, the bug is closed NOTABUG or WONTFIX. But if the bug has been reported upstream, the Fedora bug gets closed UPSTREAM. Ether way, the bug gets closed, no matter if it was actually fixed or not. IMHO filing bugs upstream is a maintainers duty. We are doing the same in Xfce or I do the same with all my packages. The only exception I make are feature requests, because I cannot support a request that I don't understand or that I am not convinced of. The use of a feature should be discussed upstream with the developers because they are in no way specific to the distribution, but bugs that affect Fedora need to be tracked in Fedora. The wiki says: > Deal with reported bugs in a timely manner > * [...] > * If there are bugs which you aren't capable of fixing yourself > because they deal with intricacies of the source code which > you don't fully understand, then you still need to address > these bugs. It can be helpful to work with the upstream > maintainer of the code, obtain help from more code-oriented > people on fedora-devel, or check other distributions for > patches. Always be sure to post to the bug report what you > have done so that the reporter knows what it happening and > what to expect. It is recommended that non-coder packagers > should find co-maintainers who are familiar with the > programming language used by their package(s), and can help > with such bugs as a kind of 'second line support'. https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Deal_wit… The Fedora KDE maintainers and bugzappers already have a KDE bugzilla account, while most of our users don't. Thus it is easier for them to file the bug than it is for the user. The maintainer has to act as a proxy between the reporter and the developer. By closing down the bugs, our bugzilla is effectively rendered useless because there is no way of searching for bugs that affect our KDE packages. Bugzilla is for tracking bugs, not for blindly closing bug reports no matter if they are fixed or not! I'd like the KDE SIG and their bugzappers to reconsider their policy: 1. Forward bugs to the upstream developers 2. Leave bugs open until they are fixed upstream and in Fedora Regards, Christoph

9 10

Help needed: patching EMBOSS to use system pcre, expat and zlib
by Julian Sikorski 04 Apr '10

04 Apr '10

Hello, EMBOSS 6.2.0 bundles zlib, expat and pcre. In the previous version, I got help from a fellow packager to patch the pcre out, but that patch no longer works. Thus, I'd like to ask for help in solving this problem, which is unfortunately beyond my skills. Ideally, I'd gladly accept a co-maintainer for this bioinformatics suite. I have built the package with bundled libs for devel for the time being, so that potential helpers have access to the latest spec file. Regards, Julian

2 5

bug no: 552456 E620 not detected - 2nd Request
by Steven James Drinnan 01 Apr '10

01 Apr '10

Hi all, I am trying to get my k3715 to work in F12 or F13. I have filled this bug report https://bugzilla.redhat.com/show_bug.cgi?id=552456 . It reports by dmesg as a E620. The modem works fine in F11 with no usb_modeswitch. But by default the CD Rom and Memory card a re disabled by default. In F12 and F13 the option driver reports a callback error of 108. But the CD Rom and Memory card are enabled. I tried usb_modeswitch. but this has no effect. In searching this seem to be Linux. wide problem across all distributions. And some distributions say that it is fixed. (not confirmed) See my bug report for more details. I am just trying to get this long standing problem fixed. Any help that I can be please ask. Steven Drinnan

3 3

Re: Upstream bugs vs. Fedora bugs: KDE people do it wrong
by Oliver Falk 31 Mar '10

31 Mar '10

I had similar issues already and I totally agree with Christoph! The maintainer should not redirect the bugreporter to the upstream bugreporting plattform. I already have plenty of accounts on upstream bugzillas because of exactly this... -of Christoph Wickert <christoph.wickert(a)googlemail.com> schrieb: >I am irritated by the way the KDE SIG and the KDE bugzappers handle >bugs. For most bugs that are reported they demand the reporter to file >an upstream bug report at bugs.kde.org and set the bug to NEEDINFO. If >the reporter doesn't respond, the bug is closed NOTABUG or WONTFIX. But >if the bug has been reported upstream, the Fedora bug gets closed >UPSTREAM. Ether way, the bug gets closed, no matter if it was actually >fixed or not. > >IMHO filing bugs upstream is a maintainers duty. We are doing the same >in Xfce or I do the same with all my packages. The only exception I make >are feature requests, because I cannot support a request that I don't >understand or that I am not convinced of. The use of a feature should be >discussed upstream with the developers because they are in no way >specific to the distribution, but bugs that affect Fedora need to be >tracked in Fedora. > >The wiki says: >> Deal with reported bugs in a timely manner >> * [...] >> * If there are bugs which you aren't capable of fixing yourself >> because they deal with intricacies of the source code which >> you don't fully understand, then you still need to address >> these bugs. It can be helpful to work with the upstream >> maintainer of the code, obtain help from more code-oriented >> people on fedora-devel, or check other distributions for >> patches. Always be sure to post to the bug report what you >> have done so that the reporter knows what it happening and >> what to expect. It is recommended that non-coder packagers >> should find co-maintainers who are familiar with the >> programming language used by their package(s), and can help >> with such bugs as a kind of 'second line support'. > >https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Deal_wit… > >The Fedora KDE maintainers and bugzappers already have a KDE bugzilla >account, while most of our users don't. Thus it is easier for them to >file the bug than it is for the user. The maintainer has to act as a >proxy between the reporter and the developer. > >By closing down the bugs, our bugzilla is effectively rendered useless >because there is no way of searching for bugs that affect our KDE >packages. Bugzilla is for tracking bugs, not for blindly closing bug >reports no matter if they are fixed or not! > >I'd like the KDE SIG and their bugzappers to reconsider their policy: > 1. Forward bugs to the upstream developers > 2. Leave bugs open until they are fixed upstream and in Fedora > >Regards, >Christoph > >-- >devel mailing list >devel(a)lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel

20 73

[Test-Announce] F-13-Beta Go/No-Go Meeting @ 2010-04-01 00:00 UTC (2010-03-31 @ 8pm EDT)
by James Laska 31 Mar '10

31 Mar '10

# F-13-Beta Go/No-Go meeting # Date: 2010-04-01 # Time: 00:00 UTC (20:00 EDT, 17:00 PDT) # Location: #fedora-meeting on irc.freenode.net Before each public release Development, QA, and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the: Go/No-Go Meeting. Verifying that the Release criteria are met is the responsibility of the QA Team. Release Criteria are set for each public release and are found at https://fedoraproject.org/wiki/Fedora_Release_Criteria For more details about this important meeting see https://fedoraproject.org/wiki/Engineering_Readiness_Meetings To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto Thanks, James _______________________________________________ test-announce mailing list test-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel March 2010