Re: Exception request from FESCo for bundled libaries
On Monday 14 December 2009 04:27:52 am Nicolas Mailhot wrote: > Le Lun 14 décembre 2009 12:45, Josephine Tannhäuser a écrit : > > of course this is a practicable rule, BUT > > the problem is upstream or the rule itself. > > > > kernels internal zlib is not a lib its a module, > > wordpress internal php-gettext is not a lib, its a php code file. > > > > The trick is to declare that a lib is not a lib and you can close the > > bug as not a bug... > > Easy cake.. > > This is playing with words. I'm sure that when the guideline was written > lib was intended as "some code in any language that can be shared". What > is less clear is the other shared components which are not code (resource > files, fonts, templates, etc) but there is no doubt at all in my mind on > the code part. > > Though your interpretation is one reason we keep refining guidelines to > leave no room for bad packager excuses. I just wanted to jump in and point out that this isn't just Nicolas picking on you, he's right. -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help wanted with dist-cvs to git conversion
On Thursday 10 December 2009 09:28:43 pm Conrad Meyer wrote: > A script that grabs the entries from FAS, and outputs everything as UTF-8 > files: > > http://konradm.fedorapeople.org/usernamelist.py I forgot to mention, this requires the 'python-fedora' package. (Doh!) Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help wanted with dist-cvs to git conversion
On Thursday 10 December 2009 09:12:46 pm Seth Vidal wrote: > On Thu, 10 Dec 2009, Jesse Keating wrote: > > I'm currently playing with a utility called parsecvs to convert our cvs > > stuff into git. This utility can also translate the raw usernames that > > CVS has into more useful names+email addresses that you'd typically get > > out of git. But to make this conversion it needs a translation file. > > > > It would be really helpful if somebody could generate a file for me that > > is in the format of: > > > > = > > > > eg: > > > > jkeating=Jesse Keating > > notting=Bill Nottingham > > > > For the initial testing, just giving every user a @feodraproject.org > > domain would be sufficient, however we should have a discussion about > > whether to use this email address or to use the user's real email > > address. > > I just did this on fedorapeople.org not against fas but I suspect that's > the same set of users. > > #!/usr/bin/python -tt > > import pwd > > for pw in pwd.getpwall(): > if pw.pw_uid < 1: > continue > msg='%s=%s <%...@fedoraproject.org>' % (pw.pw_name, pw.pw_gecos, >pw.pw_name) > print msg > > > the file with these contents is in my homedir on fedorapeople.org as: > wacky-list-for-git > > if you want me to do it directly talking to fas I'll do it in the morning. > -sv A script that grabs the entries from FAS, and outputs everything as UTF-8 files: http://konradm.fedorapeople.org/usernamelist.py Results with FAS emails (in my $HOME on fedorapeople.org): FAS-users-normalemails or fedoraproject.org emails: FAS-users-fedoraprojectemails Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packages looking for new owners
On Sunday 06 December 2009 09:03:15 pm Kevin Kofler wrote:
> Conrad Meyer wrote:
> > Also, SDCC currently does not build (clarification: the software builds
> > fine. rpmbuild is choking on non-native ar files)
>
> Try this:
> %define __os_install_post %(echo '%{__os_install_post}' | sed -e
> 's!/usr/lib/rpm/[^/]*/?brp-strip-static-archive %{__strip}!!g') (It's
> working fine in tigcc.spec to prevent tigcc.a from being corrupted.)
>
> Kevin Kofler
Ah, since my earlier email I've fixed the sdcc package under advice from
another cross lib maintainer[0]. msp430-libc (and now sdcc) just set
__os_install_post to brp-compress; I guess the advantage of sed-ing out only
the strip-static-archive is that the native binaries get stripped. I'll try
this for sdcc.
By the way, perhaps that %define should be changed to %global?
[0]: http://article.gmane.org/gmane.linux.redhat.fedora.devel/125372
Thanks,
--
Conrad Meyer
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help with packaging
On Sunday 06 December 2009 04:01:54 pm Robert Spanton wrote: > On Tue, 2009-11-24 at 19:16 -0800, Conrad Meyer wrote: > > I'm experiencing trouble trying to get one of my packages (sdcc) to build > > for Fedora 12. It builds on Fedora 11 and older (just double-checked in > > mock). It seems to be some sort of change in how RPM uses > > __os_install_post or how brp- strip-static-archive works between F11 and > > F12. Anyone familiar with any such changes? > > You might find it useful to have a look at what I'm doing in msp430-libc > with __os_install_post. I think I was inspired to do this by what was > done in avr-libc. Thanks, I'll try doing that now. Unfortunately it seems like that will stop rpmbuild from stripping the (native) sdcc binaries, but I'd like to see the package building. > RPM seems to be one of those things where knowledge is passed on by word > of mouth between generations :-/ Yes, and perhaps more work could be done with rpm to improve support for cross-compiler-related packages. > p.s. Sorry for not replying sooner -- I don't read all posts to > fedora-devel, as I would go insane :-P I'm glad to get any help. Thanks, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packages looking for new owners
On Sunday 06 December 2009 05:25:20 am Chitlesh GOORAH wrote: > On Tue, Sep 9, 2008 at 7:12 AM, Conrad Meyer wrote: > > I'd like to take sdcc. > > Can you also package http://eclipse-sdcc.sourceforge.net/ please ? > > Chitlesh Sorry, I'm not an eclipse user, and java packages are exceedingly painful to maintain. Also, SDCC currently does not build (clarification: the software builds fine. rpmbuild is choking on non-native ar files) and I am unsure how to fix it. I've asked the list a few weeks back and did not get any replies, so I may be forced to orphan it (I do not want to, but if I cannot get it to build...). Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Help with packaging
Hi list,
I'm experiencing trouble trying to get one of my packages (sdcc) to build for
Fedora 12. It builds on Fedora 11 and older (just double-checked in mock). It
seems to be some sort of change in how RPM uses __os_install_post or how brp-
strip-static-archive works between F11 and F12. Anyone familiar with any such
changes?
http://linux.dell.com/files/fedora/FixBuildRequires/mock-
results/x86_64/sdcc-2.9.0-4.fc12.src.rpm/result/build.log
Some background info for those unfamiliar with sdcc: sdcc is a compiler
targeting embedded devices. It bundles some archives that contain object code
for these other architectures -- chmodded 644, in %{_datadir} -- I don't even
know why brp-strip* dives into %{_datadir} anyway.
Thanks,
--
Conrad Meyer
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Saturday 21 November 2009 01:38:35 am drago01 wrote: > We should just use release epochs, people might hate them for whatever > reasons, but they would easily prevent such issues from happing. The problem with this system, which has been pointed out before, is that upgrades using the Fedora N release DVD on an up-to-date Fedora N-1 system will replace newer versions of packages with older ones -- this is bad. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Friday 20 November 2009 05:52:44 am Gregory Maxwell wrote: > On Fri, Nov 20, 2009 at 12:26 AM, Conrad Meyer wrote: > > On the contrary. On the typical single user system, it's just as bad if > > an attacker can steal / delete / modify the user's files as it is if the > > attacker can modify / delete system files. Privilege escalation isn't > > needed to delete everything the single user cares about. > > Not quite. For example, it's much easier to fix a system which has only > had a user account compromised, since if you actually trust that its only > the user account you can skip the full reinstall. > > This is also assuming a strictly single user system. With features like > fast user switching it wouldn't be inadvisable or especially inconvenient > to operate business and pleasure activities from separate accounts. I > don't know anyone that does this today, but as it becomes easier to do so > and if the systems don't continue to go down the route of giving the local > accounts root access then it may be a practice which becomes common. It's easier to fix the system, *if* you trust that only the user account has been compromised. However, to the user (and remember we're talking about single-user systems here), their data is much more important than system files. You can get system files back -- just reinstall. If data is lost / mangled / stolen, you can't get that data or privacy back. Yes, we're talking only about single user systems, let's not get off-track here. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Friday 20 November 2009 12:33:20 am James Morris wrote: > On Thu, 19 Nov 2009, Conrad Meyer wrote: > > > I think it's fair to say that having this happen as root would > > > generally be worse than it happening as an unprivileged user. For the > > > latter, the attacker would need to also then succeed with a local > > > privilege escalation attack to the same effect. > > > > On the contrary. On the typical single user system, it's just as bad if > > an attacker can steal / delete / modify the user's files as it is if the > > attacker can modify / delete system files. Privilege escalation isn't > > needed to delete everything the single user cares about. > > Note that I said generally. > > ... > > There are many possible scenarios where an attacker would want more > privileged access to the system, e.g. install rootkits/firmware kits, > modify firewall settings, run network services, attack other systems, > evade detection etc. IOW, the current landscape of windows malware, > data-stealing worms, botnets and so on. > > Getting root access is much more valuable in the general case. > > There are also the separate issues, as I mentioned subsequently, of > increasing the attack surface, breaking the MAC model, and executing at > full system privilege (also, without further authorization). > > I think we're throwing away a lot of well-established security benefit in > moving away from the simple model of using a root/wheel account (or sudo) > for admin and a separate user account for everything else. I agree with this. -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Thursday 19 November 2009 09:09:15 pm James Morris wrote: > On Thu, 19 Nov 2009, Owen Taylor wrote: > > Among the decisions Richard made was allowing all users to install > > signed packages from the Fedora repositories. This was clearly the right > > behavior for the common case of a single-user system, where the only > > user is also the administrator. > > I don't think this is clearly the right behavior at all. > > ... > > I think it's fair to say that having this happen as root would generally > be worse than it happening as an unprivileged user. For the latter, the > attacker would need to also then succeed with a local privilege escalation > attack to the same effect. On the contrary. On the typical single user system, it's just as bad if an attacker can steal / delete / modify the user's files as it is if the attacker can modify / delete system files. Privilege escalation isn't needed to delete everything the single user cares about. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Head-up - new firefox in rawhide
On Thursday 19 November 2009 08:57:26 am Yanko Kaneti wrote:
> Hi
>
> Would you please explain how do you come up with the
> Source0:%{name}-%{version}%{?pretag}.source.tar.bz2
> taraballs?
> Even better, include it in a comment in the spec file or the fedora wiki
> somewhere.
>
> I am trying to track a regression but having a hard time connecting
> these source tarballs to something in ftp.mozilla.org or hg.mozilla.org.
For what it's worth, I filed this bug a long time ago:
https://bugzilla.redhat.com/show_bug.cgi?id=521704
Regards,
--
Conrad Meyer
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Tuesday 17 November 2009 10:55:22 pm Josephine Tannhäuser wrote: > I think this is a script which reads your currently used architecture > and provide a dl link. please insert a x86_64 livecd and try it again! That doesn't appear to be true. I double checked that the user agent string Firefox is sending includes x86_64, and I still get the 32-bit version suggested. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken deps for rawhide the past few days
On Tuesday 17 November 2009 06:50:58 am Jesse Keating wrote: > On Mon, 2009-11-16 at 11:22 -0800, Jesse Keating wrote: > > Many of you received emails over the weekend and this morning regarding > > broken deps in rawhide. If these emails mentioned that the deps were > > broken on ppc or ppc64 they can be ignored. We are no longer producing > > ppc/ppc64 as a primary arch, however we forgot to tag the config change > > that enacted this on our compose tools. We were attempting to compose > > ppc(64) trees with only noarch packages, and well things didn't work so > > hot. > > > > We should have this fixed today so that future emails about broken deps > > will be about actual broken deps, not broken configurations. Sorry for > > the mailbombing. > > *sigh* > > While we were successful in building a new mash package that would avoid > making ppc repos, we forgot to update one of the rawhide creation > configs so that it used dist-f13 content as opposed to dist-f12. So the > rawhide creation process has been using dist-f12 content all this time > to build up the chroot, which would then compose dist-f13 content. This > means that the dist-f12 version of mash was used, not the dist-f13 > version we built to disable ppc. > > I've corrected that. Third try to kill the ppc deps should be the > charm. Could we just not send emails tomorrow, double check that it produces the correct result, and re-enable them for the next day? In case there's something else we-shouldn't-have-missed-but-we-did? -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCO ticket#270 - preupgrade and F-12
On Thursday 12 November 2009 12:43:18 pm Jesse Keating wrote: > On Thu, 2009-11-12 at 12:26 -0800, Conrad Meyer wrote: > > Is part of the reason the F-12 kernel is so much larger that the > > debugging > > switch is still flipped on? > > That's only true for the older F12 development kernels. The kernels > since 2.6.31.5-94 have had debugging turned off. Ok, that's what I was curious about. Thanks for the clarification. -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCO ticket#270 - preupgrade and F-12
On Thursday 12 November 2009 12:10:13 pm James Laska wrote: > *snip* > > So there's 174MB of usable space maximum, and usually 158MB > available. > > preupgrade now requires at least 167MB free space on /boot: > F12 installer images: 143MB (8mb larger than F11!) > F12 kernel: 18MB (10mb larger than F11!) > RPM/anaconda tmpfiles: >=8MB (measured in stupid tests) > Total: 167MB (Was 149MB in F11 - no problem!) Is part of the reason the F-12 kernel is so much larger that the debugging switch is still flipped on? Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On Monday 02 November 2009 05:55:49 pm King InuYasha wrote: > What is going on here? I thought Fedora only shipped upstream code? What's > all this business about having broken forks and licensing issues? > > The only thing I can figure out from this conversation is that the CDDL is > supposed to be incompatible with the GPL. If that's the case, why not > simply ask the original creator to kindly dual license it? In this case, upstream (wodim) is a fork of Joerg Schilling's project. Wodim was forked from cdrecord because Joerg is crazy. Joerg likes to call wodim "the broken fork" and cdrecord "the original software". Hope that helps, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
On Friday 30 October 2009 09:01:39 am Mary Ellen Foster wrote: > 2009/7/14 Conrad Meyer : > > I intend to orphan the JRuby package and some of the dependencies I don't > > believe anything else uses. It's a piece of software upstream really > > doesn't intend to be packaged, and bumping to new versions is a constant > > struggle. Furthermore, I don't have anymore use for it. Here is the list > > of packages I'll orphan sometime in the next week or so: > > > > - bytelist > > - constantine > > - jcodings > > - jline > > - jna-posix > > - joni > > - jvyamlb > > Hello! I'm sorry to come in three and a half months after the fact > (does that mean that they'll all have to be re-reviewed? :( ), but > jruby is a dependency of some Java stuff that I'm currently working on > so I'd like to take over these packages. > > MEF They're all orphaned in pkgdb. I'm not sure what process you'll need to go through to take them over (at the least, you'll probably have to talk to rel- eng to get the dead.package's removed). Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature request: AMD K10 thermal sensors
On Thursday 29 October 2009 07:08:44 am Christoph Höger wrote: > Am Donnerstag, den 29.10.2009, 14:51 +0100 schrieb Michal Schmidt: > > Dne 29.10.2009 12:38, Christoph Höger napsal(a): > > > since a year or so the AMD K10 thermal sensors module (k10temp) seems > > > to be floating around the web. I would appreciate some kernel packager > > > integrating it into the fedora 11 stock kernel - since without it I can > > > not build (and trust!) a silent cooling system. > > > > > > Any plans on this issue? > > > > AMD K10 sensors support has been repeatedly refused by upstream > > lm_sensors developers because of the sensors' unreliability. > > > > e.g. Rudolf Marek said in LKML on 2009-08-28: > > > There is a problem that all chips of fam10h have some errata which > > > renders the monitoring driver unusable. Some people proposed a > > > workaround if temps look too suspicious to refuse to load. This is > > > against a sense of monitoring to refuse the values where they don't > > > look "right". So there is no driver. > > So this means there is no chance to get my thermal sensors working under > fedora? Perhaps see if RPMFusion will carry the kmod. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Packaging files that rpmbuild's auto-{requires,provides} trips on
Hi, I'm packaging some data files for a package and having trouble getting rpmbuild to finish. At some point in (I'm guessing) the autorequires/provides scripts, file(1) returns a 1 code, and rpmbuild chokes and dies. So, my question here is: 1) How do I get these scripts to ignore this file? and also: 2) Should the autorequires/provides scripts die when they stumble across a file file(1) errors on, or should they just assume it doesn't require or provide anything? Thanks, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Who do I send to get a package removed because of bad language.
On Thursday 15 October 2009 11:39:26 pm Steven James Drinnan wrote: > I will file a ticket. > > But my point was the image of Fedora.Does Fedora want be associated with > software vendors that use this type of language? > > Steven Absolutely! As long as the software is good, I don't care what kind of language they use. Best regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: tagging of non critical path package into F-12?
On Thursday 15 October 2009 12:51:28 am Peter Robinson wrote: > Hi All, > > I presume that the reason that tagging requests aren't being done is > due to the upcoming beta but is there a reason that non core or > critical path packages can't be tagged in. I have a number of Moblin > packages that fix various issues, in particular a rebuild of > network-manager-netbook to fix networking against the latest NM build > that hit just before the cut off. Given that none of these packages > would be anywhere near any of the official spins is there any > particular reason they can't be tagged in? Or if not when will they be > reviewed? > > Peter Hi, If they're not on any of the official spins, what benefit does tagging them into dist-f12 provide over having them as updates? (Pushing updates is the suggested approach unless there's some reason it won't work in your case.) Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On Wednesday 07 October 2009 12:55:10 pm Lyos Gemini Norezel wrote: > On 10/07/2009 03:19 PM, Björn Persson wrote: > > Lyos Gemini Norezel wrote: > >> Is there valid, logical, reasoning to continue to support such old code? > > > > Are there any bugs that are so severe that we can't continue using the > > software? > > No, actually. > > Surprisingly enough... there are no current bugs open against id3lib. > > > If not: Why throw out working software just because it's old? > > Don't security risks grow exponentially as software 'bit rots'? Is it possible that id3lib is 'complete'? The id3 format isn't extremely complicated, it may just be a completely finished library. (Keep in mind, though, that I'm not familiar with the code.) As far as being a security risk... it's not a network daemon, and there's no reason it should have suid root or anything like that. I imagine the worst you could do is throw a malformed media file at it. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC update breaks PPC?
On Wednesday 09 September 2009 07:44:26 pm Michel Alexandre Salim wrote: > Has anyone noticed any problem with the PPC build servers in the past > day or so? I've been building LLVM with no problem on Koji, but today > I've had 2 virtual memory exhaustions, and now this: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1667095 > > Thanks, Maybe http://article.gmane.org/gmane.linux.redhat.fedora.devel/120454 . Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
On Tuesday 08 September 2009 07:33:10 am Michel Alexandre Salim wrote: > The latest Rawhide llvm build: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=130997 > > -- which you'd probably have to install manually until it hits the > Rawhide mirrors -- have clang's analyzer packaged. Once it lands > properly you can have llvm, llvm-clang (the compiler) and > llvm-clang-analyzer installed by simply doing > > yum install llvm-clang-analyzer > > I might push this into F-11 too, once LLVM 2.6 comes out, if simply to > provide the analyzer to our F-11 users. Please do :). Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/nss-softokn/devel nss-softokn-3.12.3.99.3-stripped.tar.bz2, NONE, 1.1
On Sunday 23 August 2009 05:43:27 pm Elio Maldonado wrote: > On 08/23/2009 12:41 PM, Kevin Fenzi wrote: > > Looks like somehow this tar.bz2 file got checked into cvs. ;( > > > > > > > > kevin > > Kevin, > > This wasn't an oversight, nss-softokn-3.12.3.99.3-stripped.tar.bz2 needs > to be there for the same reason we currently keep > nss-3.12.3.99.3-stripped.tar.bz2 for NSS, because of Red Hat's ban of > non-free sources. > > Elio These should still go in the lookaside cache and not CVS, unless there is some reason I'm not reading here. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
On Friday 21 August 2009 01:41:09 pm Aurelien Bompard wrote: > Whoops, I forgot a few more : > > - libifp -- A general-purpose library-driver for iRiver's iFP portable > audio players I have a package or two that uses this, I'll take it. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: kernel 2.6.29.6-217.2.3.fc11 compiled from source will not boot
On Sunday 09 August 2009 11:16:12 pm Markus Kesaromous wrote: > There is something seriously wrong with this kernel release. Again -- the list you want is fedora-kernel-list, NOT fedora-devel-list. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Wednesday 05 August 2009 11:48:05 pm Markus Kesaromous wrote: > I compiled the kernel without SMP support deliberately. > It is a user configurable option. If you're not using a Fedora kernel the appropriate place to complain / discuss is the LKML, not here. Even if it was a Fedora kernel, the place for this is fedora-kernel-list. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Wednesday 05 August 2009 09:58:44 pm Markus Kesaromous wrote: > I know this is a staging and thus experimental driver. > I only wanted to point out that if you compile the kernl > without SMP support, then this driver module will have these > undefined symbols: Which Fedora kernels are compiled without SMP support? Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Adding concurrency/multithreading support to par2cmdline
On Friday 31 July 2009 13:03:06 Erik van Pienbroek wrote: > [snip] > > The current version of par2cmdline in Fedora is 0.4. This is also the > latest upstream version. There hasn't been any upstream activity ever > since the year 2004 [1]. > > Some time ago, par2cmdline was forked by somebody [2] and > concurrency/multithreading support was added to it using Intel's > Threading Building Blocks. Also worth noting: AIUI the -tbb fork of par2cmdline fixes bugs that were present in the original version we currently have in Fedora, as well as taking advantage of multiple cores. There is a compile-time option to disable the TBB portions (but leave the fixes for the bugs) that we plan on using on arches other than x86 and x86_64. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: openssh-blacklist - careless waste of space.
On Thursday 30 July 2009 08:49:12 am Jan Chadima wrote: > Hi > I've just solve the problem with the openssh-blacklist package. > Now the packae is only the 16 kbytes. It contains the downloader. The data > are downloaded from the server on user request. Excuse me the first > (big)package. I hope that way will work. If I'm reading this correctly, this behavior is also broken. The user should not have to be connected to the internet to use the package after (s)he installs it. Another interpretation suggests that you download the data in the build process; that won't work on Koji (and should be fixed). Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What to do with release number on new EL-5 branch
On Sunday 26 July 2009 07:50:14 pm Toshio Kuratomi wrote:
> On 07/26/2009 01:52 PM, Conrad Meyer wrote:
> > On Sunday 26 July 2009 01:47:55 pm Richard Fearn wrote:
> >> Hi,
> >>
> >> I've just had an EL-5 branch created for my disktype[1] package. The
> >> new branch is a copy of the devel branch, so the NVR is currently
> >> disktype-9-5.
> >>
> >> Should I build the package as-is (so the first EPEL version is 9-5),
> >> or clear the changelog and start from 9-1 again for the EL-5 branch?
> >>
> >> I looked on a few pages[2][3][4] for information on this, but couldn't
> >> see anything.
> >>
> >> Thanks,
> >>
> >> Rich
> >>
> >> [1]: https://admin.fedoraproject.org/pkgdb/packages/name/disktype
> >> [2]: http://fedoraproject.org/wiki/Using_CVS_FAQ_for_package_maintainers
> >> [3]: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
> >> [4]: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
> >
> > There is nothing wrong with starting at 9-5.
>
> Using the disttag can make it clearer that a package comes from epel as
> opposed to someone installing the Fedora package onto an EL-5 system and
> expecting it to work.
>
> https://fedoraproject.org/wiki/Packaging/DistTag
> -Toshio
Er, I am not saying "don't use dist", just that starting at 5%{?dist} instead
of 1%{?dist} is completely fine.
Regards,
--
Conrad Meyer
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What to do with release number on new EL-5 branch
On Sunday 26 July 2009 01:47:55 pm Richard Fearn wrote: > Hi, > > I've just had an EL-5 branch created for my disktype[1] package. The > new branch is a copy of the devel branch, so the NVR is currently > disktype-9-5. > > Should I build the package as-is (so the first EPEL version is 9-5), > or clear the changelog and start from 9-1 again for the EL-5 branch? > > I looked on a few pages[2][3][4] for information on this, but couldn't > see anything. > > Thanks, > > Rich > > [1]: https://admin.fedoraproject.org/pkgdb/packages/name/disktype > [2]: http://fedoraproject.org/wiki/Using_CVS_FAQ_for_package_maintainers > [3]: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure > [4]: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies There is nothing wrong with starting at 9-5. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090721 changes
On Wednesday 22 July 2009 01:35:34 am Peter Robinson wrote:
> >> On 07/21/2009 09:00 PM, Rawhide Report wrote:
> >> > Compose started at Tue Jul 21 06:15:03 UTC 2009
> >> >
> >> > New package ghc-editline
> >> > Haskell %{pgk_name} library
> >>
> >> Obvious typo and it passed through review as well.
> >>
> >> Rahul
> >
> > I noticed this, but I don't think it's a typo. In the rpm it gets
> > evaluated as "Haskell editline library", I imagine.
>
> I think he means pgk should read pkg, or maybe even just use the
> standard rpm %{name} variable.
>
> Peter
Oh, wow, I didn't notice pgk either. Sorry! %{name} isn't entirely correct
because you get ghc-%{pkg_name} instead of %{pkg_name}.
--
Conrad Meyer
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090721 changes
On Wednesday 22 July 2009 01:05:23 am Rahul Sundaram wrote:
> On 07/21/2009 09:00 PM, Rawhide Report wrote:
> > Compose started at Tue Jul 21 06:15:03 UTC 2009
> >
> > New package ghc-editline
> > Haskell %{pgk_name} library
>
> Obvious typo and it passed through review as well.
>
> Rahul
I noticed this, but I don't think it's a typo. In the rpm it gets evaluated as
"Haskell editline library", I imagine.
--
Conrad Meyer
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Sage in F11
On Sunday 19 July 2009 02:05:44 pm Matthew Saltzman wrote:
> Sorry to bother the -devel list with this, but nobody on fedora-list
> responded to my question, and I know there is some effort to package
> Sage for Fedora. I hope one of those packagers can help me out.
>
> I've installed sage-4.1 on F11 using the F10 binary installation
> tarball. But when I run sage, it fails with the following error:
>
>
> /usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/sage
> --
>
> | Sage Version 4.1, Release Date: 2009-07-09
> | | Type notebook() for the GUI, and license() for information.
> | |
>
>
> --
> Traceback (most recent call last):
> File
> "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/b
>in/sage-ipython", line 18, in import IPython
> File
> "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l
>ib/python2.6/site-packages/IPython/__init__.py", line 58, in
> __import__(name,glob,loc,[])
> File
> "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l
>ib/python2.6/site-packages/IPython/ipstruct.py", line 22, in from
> IPython.genutils import list2dict2
> File
> "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l
>ib/python2.6/site-packages/IPython/genutils.py", line 59, in from
> IPython.external.path import path
> File
> "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l
>ib/python2.6/site-packages/IPython/external/path.py", line 35, in
> import md5
> File
> "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l
>ib/python/md5.py", line 10, in from hashlib import md5
> File
> "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l
>ib/python/hashlib.py", line 136, in md5 =
> __get_builtin_constructor('md5')
> File
> "/usr/local/sage-4.1-linux-Fedora_release_10_Cambridge-x86_64-Linux/local/l
>ib/python/hashlib.py", line 63, in __get_builtin_constructor import _md5
> ImportError: No module named _md5
>
> I assume I'm missing a dependency, but what is it? Or is there something
> else going on?
>
> Sage worked fine in F10. This error occurred also with sage-4.0.2 in F11.
>
> TIA.
> --
> Matthew Saltzman
>
> Clemson University Math Sciences
> mjs AT clemson DOT edu
> http://www.math.clemson.edu/~mjs
$ rpm -qf /usr/lib64/python2.6/lib-dynload/_md5module.so
python-2.6-9.fc11.x86_64
I'm guessing the version of python shipped with Sage is missing the native md5
module (which is in %{_libdir}/python2.6/lib-dynload/_md5module.so on F-11).
Regards,
--
Conrad Meyer
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaning packages
Hi, I intend to orphan the JRuby package and some of the dependencies I don't believe anything else uses. It's a piece of software upstream really doesn't intend to be packaged, and bumping to new versions is a constant struggle. Furthermore, I don't have anymore use for it. Here is the list of packages I'll orphan sometime in the next week or so: - bytelist - constantine - jcodings - jline - jna-posix - joni - jvyamlb If anyone wants any of them, let me know. (In case it's not obvious, they are all java packages.) Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: bchunk: dead package
On Tuesday 14 July 2009 03:56:34 am Michael Schwendt wrote: > https://fedorahosted.org/rel-eng/ticket/1977 > > bchunk is said to be obsolete, because "shntool" (also in Fedora) would > be superior. If you disagree and find a good reason to adopt bchunk, please > find a solution for the open ticket. > > Originally, I had sponsored Alan Olson (alano) when he wanted to take over > this old package in Fedora. A deal that hasn't worked out this time. The > single bugzilla ticket (#439661)is without a response/action since over a > year. And attempts at contacting alano via private mail and bugzilla have > been fruitless. As such, I've removed him from the FAS Packager group, too. >From reading the ticket[0], it looks like the Debian patch solves the issue -- I would like to take the package. [0]: https://bugzilla.redhat.com/show_bug.cgi?id=439661 Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: glipper (was Re: Purging the F12 orphans)
On Tuesday 14 July 2009 12:01:26 pm Christoph Wickert wrote: > Am Dienstag, den 14.07.2009, 13:23 -0500 schrieb Juan Rodriguez: > > On Tue, Jul 14, 2009 at 12:58 PM, Jesse Keating > > wrote: > > Unblocked orphan glipper > > > > If noone's taking care of glipper, I'll have to sign up, as I actually > > *depend* on glipper to function properly. > > Well, then you are lost, as it's broken for ages, see > https://bugzilla.redhat.com/show_bug.cgi?id=449890 > > I think the program is dead upstream. Use parcelite instead. > > Regards, > Christoph I had more trouble than I should have googling this one -- it's parcellite[0]. [0]: http://parcellite.sourceforge.net/ Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Can we import dia 0.97 in rawhide?
On Wednesday 08 July 2009 11:05:21 am Bernie Innocenti wrote: > It's been released here: > > http://projects.gnome.org/dia/ > > -- >// Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ File a bug. -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On Sunday 05 July 2009 11:24:43 am Sam Varshavchik wrote: > Conrad Meyer writes: > > On Sunday 05 July 2009 07:45:46 am Sam Varshavchik wrote: > >> *snip* > >> > >> With a subsequent release, you'll still > >> have to rebase your existing patch, if the new release did not fix the > >> original bug. As I understand, rpm's default settings now reject fuzz in > >> patch files, so you'll just have to do it, now. And since the likelyhood > >> of configure changing in a new release is no different than any other > >> source file getting changed, on average, believing that some work can be > >> saved just by choosing to patch a different file, then the one that > >> really needs to be patched, is somewhat naive. > > > > The problem is that configure scripts are not written by a human, but > > generated by autoconf. It is easy to make small changes to configure.ac > > and generate large changes in configure. This makes it easier to rebase > > patches against configure.ac. > > The macros in configure.ac generally expand out to canned shell script > fragments, with the macro's parameters substituted somewhere. Changing a > parameter in configure.ac usually results in an equivalent substitution in > configure. Right. Still, it makes more sense to patch the original source than the generated result, I think. > Generally, only when one adds or removes entire macros from configure.ac, > that's when this results in wholesale changes to configure. > > In my experience, the overwhelming majority of fixups to configure scripts > involve nothing more than adjusting someone's pathname, or compiler flags. > For this kind of scope, rebuilding the entire configure script is overkill, > and I wouldn't do it unless I audit it and verify whether or not upstream > is relying on some specific behavior in the specific version of autoconf > that was used to build the original configure script. Patching the > configure script is much safer than patching configure.ac, then have > autoconf grok all .m4 macros and rebuild the whole thing, likely ending up > with a completely different beast, that not only includes your changes but > who knows what else. Unrelated, but I think this sort of phobia of regenerating an auto-generated script just goes to show how completely broken autotools is. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On Sunday 05 July 2009 07:45:46 am Sam Varshavchik wrote: > *snip* > > With a subsequent release, you'll still > have to rebase your existing patch, if the new release did not fix the > original bug. As I understand, rpm's default settings now reject fuzz in > patch files, so you'll just have to do it, now. And since the likelyhood of > configure changing in a new release is no different than any other source > file getting changed, on average, believing that some work can be saved > just by choosing to patch a different file, then the one that really needs > to be patched, is somewhat naive. The problem is that configure scripts are not written by a human, but generated by autoconf. It is easy to make small changes to configure.ac and generate large changes in configure. This makes it easier to rebase patches against configure.ac. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning par2cmdline
On Tuesday 30 June 2009 01:47:37 am Laurent Rineau wrote: > I have just orphaned par2cmdline¹. I am not using that package for more > than one year, now, and I was doing the minimal maintenance (taking care of > mass- rebuilds and so on). > > Erik van Pienbroek (erik-fed...@vanpienbroek.nl) is already willing to > maintain it, as he is currently maintaining NTTPgrab, that needs > par2cmdline. See the discussion in the following bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=508772#c1 > > > ¹) https://admin.fedoraproject.org/pkgdb/packages/name/par2cmdline > > -- > Laurent Rineau > http://fedoraproject.org/wiki/LaurentRineau Erik, I'd like to join you as a co-maintainer if it is ok with you. A package I maintain also requires par2cmdline (hellanzb). Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Monday 15 June 2009 02:48:44 pm Jerry James wrote: > On Mon, Jun 15, 2009 at 3:42 PM, Bill Nottingham wrote: > > Not that it matters for Fedora, but I doubt many people are paying > > $whatever_the_price_of_RHEL_is to run on a 6, 7, 10-year old machine. And > > RHEL 5 only supports (base) i686 or greater already. > > You know, I haven't seen anybody object to the "i686" part yet. All > of the objections, as far as I have noticed, have been to the "+ SSE2" > part. I have an i586 machine currently running Fedora 10, but I don't object to switching to i686 only for Fedora 12. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bittorrent speeds...
On Tuesday 09 June 2009 08:45:27 pm Nathanael D. Noblet wrote: > Hello, >Is it just me or is the torrent a bit slow. I typically download TV > shows at 1.5MB/s (MB, not Mb). 150-300MB in 4-5 minutes. This torrent is > sitting around 20-40KB/s... Anything I can do about that? Is the tracker > swamped or ??? > > -- > Nathanael d. Noblet > T: 403.875.4613 I was getting speeds in excess of a few megabytes a second on the Fedora 11 torrents, I'm not sure why you're having trouble. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wednesday 03 June 2009 11:40:42 pm Ralf Corsepius wrote: > Conrad Meyer wrote: > > On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: > >> Let me try an analogy: How do you handle defects/malfunctions with your > >> car? > > > > Did a bunch of hobbyists from around the world build your car by > > communicating over the internet? > > Have you ever seen an open source car? > > The Fedora "car" manufacturer is the "fedora community", assembling it > from "upstream" components. > > Ralf That's the idea, opensource behaves completely different from a car manufacturer. -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: > Let me try an analogy: How do you handle defects/malfunctions with your > car? Did a bunch of hobbyists from around the world build your car by communicating over the internet? If so, I think it would be safer to stop driving immediately (EBADMETAPHOR). Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
