Re: Starting a SIG for package reviews
So, that was pretty good response; only one reply here, but several names were added to the wiki page. There seem to be enough people interested to begin moving forward. I can't think of a better place for discussion than this list, so I'll just go ahead: Could someone volunteer to co-chair this thing with me? The amount of free time I have to work on these things can be quite variable, and having someone sharing organizational duties would really help. Could someone volunteer to work with the wiki? It and I don't really get along, and I know that having a good page that gets linked from the proper places can really help in driving membership. I think it would be productive to have at least some meetings on IRC. I don't have any illusions about being able to get everyone all together at once but I've been involved here for long enough to know that some things just don't get done on a mailing list. Folks who want to attend are welcome to fill out http://whenisgood.net/43qkixx and we'll try to find something that works. (The only hard conflict I have is the FPC meeting.) Finally, I want to repeat something that's on the wiki page: you don't have to be a packager to join. I think participation in the SIG would be a great vehicle to sponsorship. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Starting a SIG for package reviews
SO == Stanislav Ochotnicky sochotni...@redhat.com writes: SO I believe you forgot to set whenisgood to use timezones :-) My understanding is that you have to log in in order to set your timezone, or that choosing a timezone was something the responder had to do. When I created the form, Use timezones was checked. Not that I'm at all an expert at using that system. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PokerTH orphaned
HdG == Hans de Goede hdego...@redhat.com writes: HdG Hi,HHdG Tomas has chosen to fix this problem by simply disabling the HdG openssl compat part of gnutls (which as the above bug shows is HdG broken by design) given that only 3 apps use this, this seems like HdG a sane choice to me. Except, of course, it appears that someone completely forgot to contact the people who maintain those applications. That's not how it's supposed to work. Given that it's only three applications, that should have been pretty easy. The point is that it's not OK to think we're only screwing three maintainers; it's OK to do this without actually talking to them. My upstream (zoneminder) explicitly removed openssl support because of the licensing issues. It can still be made to work, but of course that violates their license and I can't imagine that at this point they're going to just change their license to allow us to ship the software. Of course I'll try, but in the meantime I certainly can't actually build the software in Fedora. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fwd: Broken dependencies: vym]
IA == Iain Arnell iarn...@gmail.com writes: IA The perl_default_filter macro changed with perl 5.14. We're now IA using rpm's native __requires_exclude macro (and friends) instead of IA the slightly hacky filter_setup stuff. Really? Is there documentation for how this is supposed to work now? There's an open draft on this, but I was struggling to find enough macro magic to support the old Perl macros with the new filtering system (and failing). If this is taken care of, I'd really like to proceed with updating the filtering instructions to include mention of the new hotness. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package Review Bug#730815
NO == Nathan Owe ndowen...@gmail.com writes: NO Should I let the submitter know that it is this old or should it be NO closed or the age of the upstream source ignored, in which I am NO guessing the later is not the case. Well, I could certainly ask the submitter if they're aware that the code they're packaging is ancient and most likely unmaintained, and if they're willing to essentially take upon themselves the full maintenance burden. It's not anything that's against the rules, and I'd expect that they'd be aware of the status of the upstream project in any case since they've gone to the effort of packaging it. Old code isn't guaranteed to cause problems, and plenty of really old code works just fine today. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package Review Bug#730815
NO == Nathan Owe ndowen...@gmail.com writes: NO Yep old code does tend to work, but also this also means that NO security or runtime bugs that are around won't be fixed either, NO atleast upstream. Right, which is why I wrote that you should ask the submitter if they are willing to take on the full maintenance burden. Without an active upstream, they have to do that themselves. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fwd: Broken dependencies: vym]
IA == Iain Arnell iarn...@gmail.com writes: IA The only documentation I'm aware of is the same draft you're working IA on. Ah, OK. For some reason I interpreted what I read to say that the Perl filtering macros had been rewritten to make use of the new filtering system. I'm still hoping that's possible, but differences in regexp language and the vagaries of rpm macro expansion would seem to make it rather difficult. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpmlint complains about BSD with attribution
SB == Sergio Belkin seb...@gmail.com writes: SB I'd want to notify that rmplint warns about BSD with SB attribution, Please file a bug against rpmlint. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package review SIG dead?
RS == Richard Shaw hobbes1...@gmail.com writes: RS After some initial interest there doesn't appear to be any activity RS unless I'm missing something. Never could gather enough interest for anyone to actually do anything. Basically I stopped after I called for a couple of folks to help me with some things and there was no response whatsoever. RS I am still interested. Anyone else? These days my interest is only occasional. If someone else is actually willing to do something, then I'm willing to participate on some level. But I'm not enough of an organizer, and I don't have enough free time, to be the person who makes it happen. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
JK == Jesse Keating jkeat...@redhat.com writes: JK I don't believe you can delete a branch remotely, I think releng has JK to do it on the server. Yes, you could still ask releng to delete a JK branch, then you could re-create it with the same name and have the JK same net effect, however we don't let developers create (nor would JK we delete) the top level Fedora/EPEL branches. It'd be some other JK topic branch that would fall victim. I have on a few occasions deleted branches which were mistakenly created, including one or two top level release branches and a few weirdly-named branches that were pushed without the maintainer realizing that they would be permanent. But yes, those are outliers. SCM admins can do it, or at least they could at one point. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
JBG == Jóhann B Guðmundsson johan...@gmail.com writes: JBG How does FPC handle packagers that violate the packaging JBG guidelines? FPC is not tasked with enforcing the packaging guidelines. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
VO == Vít Ondruch vondr...@redhat.com writes: VO It would be reasonable, on the beginning of each development cycle, VO to publish a list of packages which were not touched by it VO maintainer in previous release. I certainly hope you realize that there are very many packages in the distribution that simply do not need to be touched by the maintainer all that often. Many packages will have seen no upstream changes at all for quite some time and unless we do a mass rebuild or make changes to the packaging guidelines which require updates, there is simply no need to pointlessly waste time messing with packages just to avoid appearing on some potentially horrible maintainers list. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
TH == Tom Hughes t...@compton.nu writes: TH As somebody who is in exactly that situation all I can say is that TH if doing informal reviews is an essential prerequisite to getting TH sponsored then the wiki could be a lot clearer. Currently it reads TH more like it's just one thing that may help. It is just one thing that may help. Since we give sponsors significant choice in who they will or will not sponsor, different sponsors may choose to look at different things. Most of them will want to see something that illustrates packaging experience, though. Doing informal reviews is a good way to do that. Which is pretty much what the wiki says, isn't it? - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Getting Sponsored
RS == Richard Shaw hobbes1...@gmail.com writes: RS Perhaps this has been discussed before I'm RS not aware of it but do we really need to hold up a package because RS the submitter needs a sponsor? Yes, definitely. RS Does this make sense? Yes, it makes a lot of sense. We need to set some minimal limit on the amount of knowledge packagers have before we essentially give them access to every Fedora-running computer on the planet. And we need to make sure that they have a person assigned to watch over them. Hence the current process. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
RS == Richard Shaw hobbes1...@gmail.com writes: RS How does someone who needs to be sponsored make sure that their RS informal reviews get noticed? Not everyone will 'toot their own RS horn' so to speak. That doesn't mean they are not a good prospect as RS a packager. Well, the documentation says to include that information in the review tickets for the package(s) you have submitted, along with all other relevant information which would help a sponsor in making their decision. In what way do you think that is insufficient? - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub2 and setting crashkernel kernel argument
RR == Roman Rakus rra...@redhat.com writes: RR How are fedora with grub2 users supposed to set up crashkernel RR kernel argument? Or even any argument? One possibility is /etc/default/grub. This contains GRUB_CMDLINE_LINUX. After changing that, grub2-mkconfig -o /boot/grub2/grub.cfg. You can also edit grub.cfg directly, but it gets wiped out if anything ever runs grub2-mkconfig. Finally, grubby has options for modifying kernel arguments, but I do not believe that goes in and does anything with the /etc/default/grub line so again that gets wiped out of anything runs grub2-mkconfig. The grub2 situation is definitely suboptimal at this point. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
MS == Michael Schwendt mschwe...@gmail.com writes: MS More than a dozen Red Hat people with commit access, but access MS was denied to one other Red Hat employee. Why? You'll find that for some odd reason xiphmont has commit set to Denied on several packages. I've never understood why it ended up that way. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
RWMJ == Richard W M Jones rjo...@redhat.com writes: RWMJ Is there any essential difference between 'fedpkg push' and plain RWMJ 'git push'? def push(self): Push changes to the main repository cmd = ['git', 'push'] _run_command(cmd) return So looks like no. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reminder: Bugzilla UPGRADE to 3.6 on August 13th 9:00 p.m.EDT [01:00 UTC]
JP == John Poelstra poels...@redhat.com writes: JP Also *PLEASE* make sure any scripts or other external applications JP that rely on bugzilla.redhat.com are tested against our test server JP before the upgrade if you have not done so already (see original JP email below). Unfortunately the test instance is down at the moment. Bugzilla has suffered an internal error. Please save this page and send it to bugzilla-ow...@redhat.com with details of what you were doing at the time this message appeared. URL: https://partner-bugzilla.redhat.com/ - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
BN == Bill Nottingham nott...@redhat.com writes: BN I can't help but note that the slips have become more frequent as we BN started to actually *have* release criteria to test against. We BN didn't slip nearly as much when we weren't testing it. To me this implies that we should begin testing earlier (or, perhaps, never stop testing) and treat any new failure as an event of significance. It's tough to meet a six month cycle if we spend half of it telling people to expect everything to be broken. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
MM == Mike McGrath mmcgr...@redhat.com writes: MM Possibly also stop changing earlier? Not necessarily. We should certainly try to get the earth shattering changes done as early as possible (i.e. soon after branch) but I recognize that there isn't sufficient developer time available to both stabilize one release and push all of the new stuff through rawhide at the same time. MM It's hard to test a moving target. Well, you test what you have at the time. That may not be what you could test tomorrow, but the testing is still equally valid. MM Would an 8[1] month cycle cause fewer slips per release? Fewer MM bugs? Well, don't forget that since we aren't freezing rawhide, we essentially have that long now. F15 branched, what, a few weeks ago and isn't due to be out until six months after whenever F14 ends up coming out. I guess I'm just saying that, if we had the developer time to do it, it would be super nice if we could get the pre-F15 rawhide is useless bit over and done with by the time F15 branches. But back in reality, I know that's a tough thing to ask for. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
JN == Joe Nall j...@nall.com writes: JN On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote: More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden capabilities are present on a binary? 'ls' doesn't mention anything. JN getcap Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages. I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature
Yeah, it looks like the capabilities thing has broken my buildsystem: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported I don't use the mock tmpfs plugin; I just have a big tmpfs mounted on /mock that everything is built in. grep mock /proc/mounts tmpfs /mock tmpfs rw,rootcontext=unconfined_u:object_r:default_t:s0,seclabel,relatime,size=10485760k,nr_inodes=1048576,mode=2775,gid=219 0 0 I'm thinking that tmpfs simply doesn't support capabilities, which would be... unfortunate. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
SO == Stanislav Ochotnicky sochotni...@redhat.com writes: SO Java SIG has prepared changes in current Java packaging SO guidelines. We would welcome wider discussion/comments at this SO point. From our point of view guidelines seem ready for approval by SO FPC. Could we get a diff of these guidelines against the guideline changes that FPC recently approved? - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
SO == Stanislav Ochotnicky sochotni...@redhat.com writes: SO Java SIG has prepared changes in current Java packaging SO guidelines. It's terribly rude to crosspost to a list which simply rejects messages from non-subscribers. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes in Java packaging guidelines - RFC
SO == Stanislav Ochotnicky sochotni...@redhat.com writes: SO Recently? I haven't heard of Java-specific guideline changes for SO past few months. Care to enlighten me? https://fedorahosted.org/fpc/ticket/13 http://lists.fedoraproject.org/pipermail/devel-announce/2010-October/000699.html - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
RC == Ralf Corsepius rc040...@freenet.de writes: RC In other words, as far as I am concerned, abrt has reduced RC efficiency of bug-hunting by flooding maintainers with low quality, RC often unusable reports and risen the communication churn related to RC BZs. It's been discussed many times and I still believe that it would be extremely beneficial for ABRT to remain, but to store its data somewhere other than bugzilla. Perhaps this speaks more to deficiencies in bugzilla, but it really doesn't seem to be the proper repository for the information that ABRT is producing. Not only do you need an account in order to report things, but the ABRT client is responsible for trying to eliminate duplicates (which it's getting better at, I admit). And bugzilla really makes it difficult to manage large numbers of bugs, which is a problem in itself but certainly not helped by ABRT piling on. But I guess without someone stepping up and implementing non-bugzilla storage for ABRT and the tools required to query that data, this is all just idle talk. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request for intel driver update in rawhide
RK == Rudolf Kastl che...@gmail.com writes: RK Hello, I wanted to point out that about a month and a half ago intel RK released a new driver version 2.13.0. Could we please have an update RK in rawhide? Currently rawhide seems to be at 2.13.901, a development version past the one you are requesting. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request for intel driver update in rawhide
RK == Rudolf Kastl che...@gmail.com writes: RK http://koji.fedoraproject.org/koji/packageinfo?packageID=7794 RK guess you pulled that somewhere else. fedpkg co xorg-x11-drv-intel; less xorg-x11-drv-intel/*spec - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: debugging build hang in koji ?
A few folks have sufficient access to log into the builders and strace things if necessary. You're welcome to ping me on IRC. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 'tig' package update change
LZ == Lukas Zapletal lzap+...@redhat.com writes: LZ Hello, I have noticed that latest tig update in Fedora 17 changed LZ it's behavior. tig has not ever been updated in F17; it still has the same 0.18-2 release that was there when F17 was spun. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 : broken configuration for httpd 2.4
It would have been super nice to actually include a link in all of those bugs, or some reference. I mean, they must have been filed by program, so it's not as if you would have had to do a bunch of extra typing. We really need a mass bug filing howto or something. Preferably starting with Don't. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 : broken configuration for httpd 2.4
RC == Remi Collet fed...@famillecollet.com writes: RC Have you notice than all this bugs depend on #871373 which provides RC some useful information ? The useful information was not in the ticket. Which means it wasn't in the email. Which means I had to get over to a web browser, wait for bugzilla to load, and click around (and wait some more) to figure out what on earth was going on. People seem to think this is a great thing, and yes, I applaud Remi for trying to help, but mass-filing tickets is the last resort, to be used after doing a proper announcement and having discussion. nirik are working on a proposal for some policy here. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using generally useful macros
NU == Nikolay Ulyanitsky lys...@lystor.org.ua writes:
NU Some maintainers use them, some do not.
I guess people who really like extra typing, wrist pain or spec files
which are difficult to read would use them.
NU What is recommended way?
It's up to you, but something like %{__cp} is absolutely pointless and
five shifted characters longer than cp. When doing package reviews
(on the rare occasion these days that I have time to do them) if I see a
spec that uses that kind of junk I simply skip right over it.
- J
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 install timings
OP == Orion Poplawski or...@cora.nwra.com writes: OP The install spends a long time displaying Checking dependencies in OP packages selected for installation with no movement of the progress OP bar. My kickstart installs used to sit showing that for ages; I ended up using pungi -G to gather an install set of just what I have in the kickstart file. This seems to make things run much, much faster, although I've never worked on figuring out why. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need a sponsor for beakerlib
JL == James Laska jla...@redhat.com writes: JL Greetings folks, Is anyone interested in sponsoring a new package JL used in several upcoming AutoQA test cases? We don't sponsor packages, we sponsor packagers. Has the packager in question done any other review work? Submitted other packages for inspection? Read http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group? - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need a sponsor for beakerlib
AW == Adam Williamson awill...@redhat.com writes: AW I think it was just a thinko for 'review'. In which case, why would a sponsor be required at all? James is in the packager group, so he could just do the review. According to the ticket in question, a sponsor for the packager is required (FE-NEEDSPONSOR is blocked). - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need a sponsor for beakerlib
JL == James Laska jla...@redhat.com writes: JL I take it from your response that you're not interested in reviewing JL and sponsoring this package review request? Again, we don't sponsor packages or package review requests. We sponsor packagers. Packagers need to demonstrate various things before someone will sponsor them. This is separate from the acceptability of the package itself. All you should take from my response is a set of questions that will need to be answered before someone's going to step up and sponsor the packager. Whether or not I have any personal interest in this particular package or packager has nothing to do with that. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: potentially unmaintained packages
TK == Toshio Kuratomi a.bad...@gmail.com writes: TK Querying bugzilla is a comparatively expensive process so it's TK probably something we need to do by syncing the count of bugs into TK the db via a cron job. Any takers? I could probably whip something up. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sched_autogroup interactivity patch for the desktop
IG == Ilyes Gouta ilyes.go...@gmail.com writes: IG Can we have this patch back ported into the current kernel for IG Fedora 14 and possibly posted as an update? :) IG Would be wonderful! Would be more wonderful to wait until the upstream development has actually finished before cramming it into our packages and hoping it actually works. If you really want it, Fedora provides all the tools to build your own custom kernel package. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Milmeister Mass-Orphaning Request
RWMJ == Richard W M Jones rjo...@redhat.com writes: RWMJ I will take ocaml* and unison*. I have orphaned them; feel free to take ownership. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bastion02.fedoraproject.org listed in sorbs.net DNSBL - can we get some better spam filtering so I don't end up blocking feodora's emails?
MF == Mike Fedyk mfe...@mikefedyk.com writes: MF Hopefully some better spam filtering can be implemented so that MF fedora's mail servers don't end up in spam block lists anymore. Spam filtering will never prevent every spam from getting through. The host forwards lots of mail; people are going to falsely report it as a spam source. Honestly (were it my machine) I'd try to get a sample, look through the MTA logs to figure out who the supposedly spammed person was, and ask them why in the hell they incorrectly reported the machine as spamming. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Milmeister Mass-Orphaning Request
PP == Petr Pisar ppi...@redhat.com writes: PP I can take: pl, yap. They should be orphaned in pkgdb; you'll need to log in and take ownership. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Howto: Create a new package and retiring a package
SD == Steve Dickson ste...@redhat.com writes: SD So what/where are the steps I need to take to retire nfs-utils-lib SD and create a new libnfsidmap package... http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life And I think you're probably pretty familiar with the process of submitting new packages to the distribution. Review ticket, review, SCM request, import, build, update. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Appeal to finish the change in maintainer for the openjpeg package.
AH == Adam Hough adam.ho...@gmail.com writes: AH Someone with that right permissions need to change who maintains the AH openjpeg package in Fedora. It has two comaintainers, so I don't really see what the issue is. I went ahead and gave those comaintainers approveacls permission on the Fedora branches so they can add other committers if they desire. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
MP == Michał Piotrowski mkkp...@gmail.com writes: MP How can I get information about all packages that provides init MP scripts? repoquery --whatprovides '/etc/init.d/*' - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
PM == Panu Matilainen pmati...@laiskiainen.org writes: PM In particular, I'm interested in feedback on the new, pluggable and PM enhanced dependency extration system. Documentation is scarce at the PM moment but some background and examples can be found here: PM http://laiskiainen.org/blog/?p=35 Unfortunately laiskiainen.org isn't responding for me at the moment, so I can't check the actual packages, but could you comment on whether rpm-builds dependency list will be changing as a result of this? Because if so we'll have to work through a round of build failures as things which used to be in the buildroot purely due to rpm-build might no longer be there. I'm thinking of perl in particular. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer for libical
MC == Milan Crha mc...@redhat.com writes: MC Could you give me a link to the proper PackageDB MC page, please? Personally I just go to http://bugz.fedoraproject.org/packagname and click the Package Info link. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora default services
MP == Michał Piotrowski mkkp...@gmail.com writes: MP Dear FPC people, could you provide this list in the near future? We haven't even met since it was decided that we were to do this. I imagine it would take a couple of meetings to bang out a list. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
PR == Peter Robinson pbrobin...@gmail.com writes: PR My understanding was that if it was blocked it had to go through PR review again. Depends on how long: http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers Re-review required for older packages If a package was last updated more than three months ago (running git log *.spec can show you this information), you will need to submit a review request (a new bugzilla ticket) and have the package approved by a reviewer as if it were new to Fedora. See the package review process for more information. There are a couple of small changes though, be sure to submit a 'update' request to the SCM, and before you will be able to run the final 'make build' commands you will need to file a ticket w/ release engineering to unblock your package https://fedorahosted.org/rel-eng/newticket I note that you'd probably never find that policy if you didn't already know what to search for, and that I need to add some additional info somewhere about how to make the SCM request. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retired package by mistake - undo?
GD == Gilboa Davara gilb...@gmail.com writes: GD Hello all, While the click-frenzy required to take ownership over GD spring and its sub packages I mistakably retired spring-maps-default GD / devel and spring-install / devel. I tried to unretire them both, GD but failed. You've found one of the worst ways to reach an admin, of course, but I happened to notice your message. I unretired spring-maps-default. I can find no packages named spring-maps-devel, spring-install or spring-devel in pkgdb. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retired package by mistake - undo?
OK, I found spring-installer and unretired it as well. You should log into pkgdb and claim both packages as they're currently orphaned. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal to improve the Sponsorship process on Fedora
JS == Jochen Schmitt joc...@herr-schmitt.de writes: JS because I have read, that new contributors should not applies JS membership on the packagers group and the sponsor should invites JS them to this group, Well, nobody can apply to the packager group; it is invite-only. There may be a few people in the sponsorship queue from before the invite-only functionality was implemented. If I understand your proposal, you simply dislike that adding someone to a group involves typing their FAS ID into the add to group box and then clicking the sponsor link, and you'd prefer to bypass the second step? I suppose I can see the point, although the issue seems awfully minor to me. Did you have a patch implementing this? - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a new scm module for a new package
Well, you missed yesterday morning's run and I skipped over that package in this morning's run because the ticket isn't assigned to anyone. I intend to go back over the tickets I skipped, figure out what's gone wrong with them and add comments but I have not yet found the time to do that today. As always, making sure that the procedures are followed makes everything run more smoothly. https://fedoraproject.org/wiki/Package_Review_Process documents the review process, including indicating that the review ticket should be assigned to the reviewer. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
JC == Jon Ciesla l...@jcomserv.net writes: JC I can't recall at the moment where this stems from, but the JC rationale, as I recall, was that we can never be sure if the JC database is available at RPM install/upgrade time. It's pretty simple. Creating databases isn't generally something that an rpm can do on its own; for mysql, at least, rpm certainly won't have any way at all to get at local administrative password. And of course databases can be on remote machines, so such packages rarely have dependencies on the actual database server anyway (just the client libraries) and certainly no way to figure out where the remote server is or how to access it. Now, sqlite would be a different matter. It would still be terribly antisocial for a package to wipe out existing data on an upgrade, but creating and managing sqlite databases is something that could be done by the package (although I'd still think that's better left for runtime). - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gtk2 2.99.0
MC == Matthias Clasen mcla...@redhat.com writes: MC * gtk-update-icon-cache-3.0 and gtk-builder-convert-3.0 have been MC dropped (since they were identical to their un-suffixed cousins in MC the gtk2 package). If you are using gtk-update-icon-cache in %post MC of a gtk3-using package, you should add Requires(post): MC /usr/bin/gtk-update-icon-cache (and similar for %postun). I believe this is incorrect, or at least in conflict with the packaging guidelines. Those guidelines provide scriptlets which handle gtk-update-icon-cache not being present, and explicitly indicate that dependencies should not be added. If the guidelines are incorrect, please let the packaging committee know so that we can get them changed. http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
ss == susmit shannigrahi thinklinux@gmail.com writes: ss Not sure where it should go inside packaging guidelines. Can anyone ss else please do that? Packaging guidelines are modified by the packaging committee and are not generally editable. You are welcome to submit a draft for consideration; just create your draft somewhere on the wiki (your personal space is a good place) and open a ticket at https://fedorahosted.org/fpc/ including the URL of your draft. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can someone please give this ticket some attention?
NM == Nathaniel McCallum nathan...@natemccallum.com writes:
NM https://bugzilla.redhat.com/show_bug.cgi?id=625187 This bug
NM basically makes Fedora completely unusable in rawhide for NVA{3,5,8}
NM users.
Isn't that just https://bugs.freedesktop.org/show_bug.cgi?id=26980 ?
If so, the hardware is basically unsupported and needs significant
reverse engineering to be useful.
- J
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm-buildroot-usage
AW == Adam Williamson awill...@redhat.com writes: AW that's not the problem. rpmlint just thinks you usually shouldn't do AW anything with the build root in certain sections of spec files and AW so complains if it sees usage of any buildroot definition AW ($RPM_BUILD_ROOT or %buildroot) in those sections, IIRC. Well, the guidelines say: http://fedoraproject.org/wiki/Packaging:Guidelines#Scriplets_are_only_allowed_to_write_in_certain_directories Of course, that governs writing, and rpmlint can't really tell if something intends to read or write, so it warns when it sees mention of buildroot in potentially problematic places. As with many rpmlint complaints, you should simply indicate in your review ticket why you believe the usage is justified. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110122 changes
RWMJ == Richard W M Jones rjo...@redhat.com writes: RWMJ I thought that was all I had to do, but apparently there's RWMJ something else needed to drop it entirely. Did you delete all of the files and add a dead.package file? http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110129 changes
New package: ghc-process-leksah-1.0.1.4-2.fc15 Haskell process-leksah library Is it not possible to try a little harder to write a useful package summary? Or for the package reviewer to take just a quick look and notice that a summary such as that is pretty much completely useless? - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package for Fedora and EPEL from one spec source?
GvE == Gerd v Egidy li...@egidy.de writes: GvE What is the best way to handle this? Can I keep one spec for both GvE and use conditionals to always build the right way? You can. Do keep in mind, however, that the amount of conditional garbage you have to pile into the spec file can get to be a bit much, and it is often much simpler to just have a different spec on el5. These days modern Fedora packaging has diverged quite significantly from what can be supported on el5. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package for Fedora and EPEL from one spec source?
MC == Michael Cronenworth m...@cchtml.com writes: MC I don't know why, but it wouldn't be a bad thing to have it in the MC repository like a normal package, IMO. Not that this will really explain anything, but: https://bugzilla.redhat.com/show_bug.cgi?id=563176 - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging only a subset of a tool collection
TM == Till Maas opensou...@till.name writes: TM Is there any reason to only package the two tools I need and add TM others whenever someone requests it? Would someone disapprove this TM in a package review? I don't see what would require you to package every piece of functionality included in a upstream tarball. Certainly you should include sufficient comments in the spec to make the situation obvious. Just be mindful that at some point someone else may need some of the functionality you don't currently package, and conflicts may arise because of this. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package SCM admin requests
SB == Sergio Belkin seb...@gmail.com writes: SB I've made yesterday a Package SCM admin request and I haven't SB received a notification yet. Well, you made your request just after I had processed the queue yesterday and chose to complain before I had processed the queue this morning. SB I'm not in a hurry but on earlier requests I had receive answer SB after a few hours: You should be a bit more patient. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mass rebuild of mysql packages in F-15
TL == Tom Lane t...@redhat.com writes: TL Do we need to wait around for somebody to fix these stragglers, or TL can we go ahead and release dist-f15-mysql into the general TL f15-testing pool? Please do not wait on zoneminder. It was broken before this due to an unrelated issue which should be fixed up soon. Unless this Mysql bump introduces some significant incompatibility problem everything should be fine when I get the latest snapshot packaged up. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: File bugzilla-4.0-1.fc14.src.rpm uploaded to lookaside cache by eseyman
ES == Emmanuel Seyman emmanuel.sey...@club-internet.fr writes: ES It's a mistake. I wanted to upload the source tarball and picked the ES wrong file. Is there anything for me to undo? It is pretty much permanently in the git repository, and anyone who does a non-shallow clone of the package will have to download that file. There's a way to rewrite past history, but it has so many drawbacks that we may not be able to use it. And before anyone asks, I already created a hook that prevents this kind of thing. What remains is to actually hook that up to all of the existing repositories. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: File bugzilla-4.0-1.fc14.src.rpm uploaded to lookaside cache by eseyman
Erm, I guess I misread. I thought the file had been checked into git, rather than uploaded to the lookaside. Checking big binaries into git is a problem, uploading them to the lookaside isn't. I can remove it from the lookaside if that's really necessary, but there's really not much reason since it has essentially no impact except for a small amount of disk usage on the server. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Some changes to EPEL package reviews
GH == Garrett Holmstrom gho...@fedoraproject.org writes: GH How is this any different, given that process-git-requests creates a GH rawhide branch without regard to whether one asks for it or not? I'm catching up with mail after the weekend and noticed this unusually pointed bit of misinformation which bears correcting. process-git-requests has no choice in the matter. Whatsoever. It creates the branches requested; the master branch comes along regardless. I can't imagine this is remotely a big deal, but being able to differentiate EPEL-only packages does make it possible for process-git-requests to automatically dead.package the branch or to make use of any potential master-branch-less functionality should it appear in the future. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Inclusion/Exclusion of BuildRoot tag and %defattr
TK == Toshio Kuratomi a.bad...@gmail.com writes: TK They are now optional but there's no need to force people to be rid TK of them. In particular, some people like to build a package for both TK Fedora and EPEL-5. In this case, a lot of the things that are TK optional in Fedora have to remain for the EPEL package. Note that according to our guideline page only RPM releases older than 4.4 require %defattr, which would limit the requirement for it to specs which need to build unmodified on EL4. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Starting a SIG for package reviews
For a while now I've wanted to get some sort of package review SIG going. The package review process hasn't really evolved much since it was instituted way back when, and now it (and the portion of the sponsorship process it overlaps) has become a major bottleneck in one of the main ways of getting new contributors into the project. I'm (once again*) looking for a few good volunteers to get the SIG off the ground. In the past every discussion about starting this SIG has sidetracked off into grand discussion about tools that can take care of the process, but at the start I'd like to focus on organization. How many people can we muster? Do we need to have some sort of regular IRC meetings? How can we best attack the ever-growing review queue? Once we have some basic things figured out and reasonable-sized group of people involved, we can move on to the big issues of policies, modifications to the process, working with FESCo and, yes, tools. So, if you want to help out, feel free to reply. Add yourself to https://fedoraproject.org/wiki/SIGs/Package_Review#Members if you like. If you have ideas, add them to the brainstorming section there as well. *) Yes, I've tried to do this before, a good three years ago. It didn't get off the ground then, but it's never too late to try again and the need for this SIG is, I think, more pressing now than it's ever been. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposal for revitalizing the sponsorship process for packaging
For a while now I have been working on a proposal for some changes to both the way we elevate packagers to sponsors and what (to a small extent) sponsors actually do. Please note that this is not a proposal for any changes to how people are made members of the packager group in the first place and does not change the privileges of existing sponsors. My proposal is at https://fedoraproject.org/wiki/User:Tibbs/RevitalizingSponsorshipProposal I've run this by FESCo, whose response was favorable, so I'm sending this to a larger audience. Please let me know what you think. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for revitalizing the sponsorship process for packaging
KD == Ken Dreyer ktdre...@ktdreyer.com writes: KD Looks good to me. I was unaware that sponsors are (currently) also KD provenpackagers. I've considered the idea of becoming a sponsor KD myself, but when I read the archived tickets where other people KD smarter than me have been denied, the barrier to entry seemed too KD high. Yes, that's the problem I'm trying to address. KD Could you expand a bit on what you consider high-quality, KD non-trivial package reviews ? As explained in the proposal, that's intentionally left vague. The idea is to have the sponsors discuss whether the reviews meet the criteria. If the authority for elevating packagers to sponsors were delegated to the sponsors, we could even work out refinements to this ourselves. Currently it's in the hands of FESCo and to my knowledge there are no published criteria available. I know I have my own opinions, which might not be the same as those of everyone else. For the record, my opinion would be something close to package reviews which are comprehensive, don't miss important packaging problems and aren't entirely of identical autogenerated Perl modules or the like. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for revitalizing the sponsorship process for packaging
MS == Michael Schwendt mschwe...@gmail.com writes: MS There are a few unfortunate sections in the first paragraph already: Except that they're all true. users have to go through an almost endless set of steps (which also needs revision, but that's another topic) MS Compared with a few years ago there are many newbie-packagers, who MS apparently are not interested in the 'Packaging' related Wiki pages MS and not in the 'ReviewGuidelines' either. That's not really within the scope of the document. I haven't proposed lowering the standards for reviewing packages. And yes, this is a problem, but as stated by the parenthetical note which you quoted, it's not the problem I was targeting with my proposal. MS It's disappointing to see that your activity report does not cover MS activity in the review queue. Since the focus of the document is sponsorship, simple activity in the review queue was beyond the scope of what I'm trying to do. And in any case, I did state that getting useful statistics out of bugzilla for this is beyond what I am able to do. Maybe you could come up with some, though; I'd certainly be happy to look at them. MS I may be one of those, who has not sponsored anyone in the past MS year, but I post helpful (and detailed) review comments regularly MS and encounter inactive package submitters both in the normal queue MS and in the needsponsor queue. And that's great, thanks. MS Forcing sponsors to fulfill such criteria is the wrong way IMO. It MS may result in even more blanket-approval sponsorships. I don't happen to agree, but at some point shouldn't sponsors do something? Otherwise why do they have permission? What do you suggest as expanded criteria for keeping sponsor access? Or do you advocate no criteria at all, and sponsorship is lost by vote? Or are you saying it should never be lost once gained? - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for revitalizing the sponsorship process for packaging
MS == Michael Schwendt mschwe...@gmail.com writes: MS Are we talking past eachother? :-/ I don't believe so, no. I do believe that you are reading something into my proposal that simply is not there, however. MS What if sponsors _try_ but for some time haven't found anyone who MS shows enough interest in the Fedora Packaging? I've amended my proposal to the following: Sponsors should expect to participate in the review of at least one NEEDSPONSOR ticket per year, assuming there are sufficient new packagers who require sponsorship and sufficient packages within the realm of expertise of the sponsor to fulfill this requirement. Although that isn't the cleanest of constructions, ugh. MS What if there are sponsors with expertise in special areas, who are MS available to help'n'sponsor other contributors in such areas only? That was intended to be covered by the assuming there are sufficient... language in the proposal. I have revised it as above since it obviously wasn't clear to all. MS What do you gain by removing sponsors so violently? Firstly, I must state that I believe your definition of violence must differ significantly from mine. I do not believe I have mentioned any type of physical force intended to hurt, damage or kill someone or something or strength of emotion or an unpleasant or destructive or natural force. I sincerely hope I'm not just being trolled here, because I've put a lot of effort into this and I chose my words carefully. Now, I do request that you re-read my proposal. There is one instance of language involving loss of sponsorship: Loss of sponsorship is automatic if the account goes inactive or is disabled (in FAS terminology). It can always be requested again. I don't see what value there is in keeping sponsorship status on accounts which have been marked inactive. Those accounts have no access to any Fedora infrastructure in any case. Why should they show up in any list of prospective sponsors? MS For me it would be like slamming a door into my face, and I would MS likely discontinue spending time on visiting bookmarked pages like MS http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html and MS the normal review request queue. I'm really not seeing the need for the drama here. MS Sponsors can leave the group in FAS themselves. Of course they can. Perhaps if my proposal is accepted you can submit your very reasonable proposal for how sponsors leave the group. I've rather intentionally left it out of my proposal because I've wanted to avoid just this type of discussion. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for revitalizing the sponsorship process for packaging
MR == Matthias Runge mru...@matthias-runge.de writes: MR exactly, I fully agree. I think, we should lower the barrier to MR become a sponsor, maybe dropping the necessity to become a proven MR packager first. I can't quite tell; are you aware that this is the core point of the proposal I've put forward at the beginning of this thread? MR In many cases that is really not needed; a sponsor MR could/should become co-maintainer of the first packages of a new MR packager. That's in the proposal, too. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Changes to the process of becoming a packaging sponsor
A while back, FESCo approved and I implemented some changes to the process of becoming a sponsor in the packager group, and I wanted to make sure that everyone is aware since the path to becoming a sponsor is shorter and simpler than ever before. The most important change is that sponsor status no longer implies provenpackager status. Sponsor status is now solely about helping new packagers through the process. We now use the following simplified criteria for new sponsors: * Maintain at least three packages. * Have done five high quality, nontrivial package reviews. * Have been a member of the packager group for at least one release cycle (generally six months) so that you have seen the process of branching for a new release. Requests for sponsor status are now made via a trac instance: https://fedorahosted.org/packager-sponsors/ and are voted on by the existing sponsors. One final, and less-related change, is that the above trac instance can also be used by new packagers to request fedorapeople access for their packages during the review process. This replaces (or at least augments) an informal procedure by which people had to find the right person after their review had been posted or come to IRC at the right time to get fedorapeople access. So, if you believe you meet the above criteria and would like to sponsor new contributors, please feel free to step up and file a ticket in our new trac instance. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
TL == Tom Lane t...@redhat.com writes: TL Did that packaging guideline get reverted already? No, it didn't, but of course you know the packaging committee cannot prevent an upstream from implementing whatever functionality they like. We can of course revisit the prohibition if someone cares to file a ticket. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [mydns/f17] Migrate to systemd.
IRP == Itamar Reis Peixoto itama...@fedoraproject.org writes: IRP Summary of changes: 73f7b54... Migrate to systemd. (*) I'm sure you already know this, but just in case, please note that migrating to systemd within a release is forbidden. You really shouldn't even be committing any kind of systemd migration to git on any branch other than master right now. (After F18 branches but before release, you can of course commit such a migration to the f18 branch.) See the warning box under http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Swaps for sugar activities
DC == Dan Callaghan dcall...@redhat.com writes: DC I will take all three (they look straightforward :-) in exchange for DC saslwrapper: Since you appear to be familiar with sugar, is there any possibility that you (or anyone else who is familiar with sugar stuff) could cast a glance at https://bugzilla.redhat.com/show_bug.cgi?id=708663 ? This poor guy has been waiting for nearly 13 months for someone to look at his package. I can do the bulk of the review and the sponsorship if no sponsor/sugar expert is available but I don't know how to actually do any testing of sugar-related things. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
PU == Patrick Uiterwijk puiterw...@gmail.com writes: PU Hello, Would it be a possibility for me to pick up one of the PU orphaned packages, without being sponsored into the packager group PU yet? The answer is of course no, but he's now been sponsored and is free to take ownership of some of those packages. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Doesn’t LDD break no-content rule?
MC == Matej Cepl mc...@redhat.com writes: MC Isn't it breaking MC https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content MC ? Maybe you should tell us why you believe it is. I don't see how it violates any of the rules for content. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Doesn’t LDD break no-content rule?
MC == Matěj Cepl mc...@redhat.com writes: MC (sorry, once more, this time to the correct address) And now a public reply MC I thought that the rule is that Fedora packages shouldn't contain MC just a pure content. That is incorrect, pretty obviously if you think about it. I mean, how is man-pages really any different? Since you included the URL in your original message I assume you were familiar with the section, but just in case, do read http://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content Specifically: If the content enhances the OS user experience, then the content is OK to be packaged in Fedora There's a set of restrictions; I don't see how the content in the package you reference violates any of them. Documentation certainly qualifies, whether it's packaged along with the software it documents or separately. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: No f18 in bodhi
RC == Ralf Corsepius rc040...@freenet.de writes: RC Hi, f18 seems to be missing in bodhi. RC I.e., ATM, it seems impossible to push packages to f18. Until today, f18 is like rawhide; you build and it goes in at the next compose. After the switch is made, f18 acts like f17. That should happen today; I do not know exactly when it will happen. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
RWMJ == Richard W M Jones rjo...@redhat.com writes: RWMJ I just received about a dozen bugs like this: Yep, someone has taken it upon themselves to mass-file a bunch of unnecessary tickets. When FPC makes guidelines changes, they aren't generally accompanied by some mandate that existing packages be changed. In fact, I can't think of a time when a change was made retroactive. If there was something that had to change in a bunch of packages, we'd at least try to organize a labor pool to get that done without having to endlessly bug every package maintainer. So someone I've never heard of is filing a bunch of tickets telling everyone to change their packages. I really can't imagine how that's supposed to inspire a lot of joy. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mate-Desktop
Ri == Rave it chat-to...@raveit.de writes: Ri For your information. I stoped working for the Mate-Desktop project Ri for f18 because for me it is imposssible to to work together with Ri Dan Mashal. One of the reason for my decision is this last talk with Ri Dan Mashal today. I've watched a bunch of this go on and I agree that this person has overstepped the bounds of reasonable behavior on more than one occasion. I just wanted to ask that you not let the actions of one person color the entire community. I'm sure that a reasonable solution can be worked out in time. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
GH == Garrett Holmstrom gho...@fedoraproject.org writes: GH I am pleased that I got a bug report and not an involuntary patch, GH as it gives me a chance to take care of special cases and schedule GH things appropriately. I would much have preferred to receive an announcement about what should be done, some discussion about the best way to do it, and then some time to do it, after which tickets could be filed. Mass-filing a load of bugs just pisses people off, especially for something that isn't even mandatory. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Anaconda and Mouse Buttons
JF == John Florian john.flor...@dart.biz writes: JF Now, if the mouse pointer could also reverse upon detecting the JF apparent handedness of the user, well that would be one of the JF coolest UI tricks ever. I certainly hope not; I'm left handed and would never dream of switching the mouse around, given that the standard arrangement is far more advantageous to left-handed folks than it is to right-handed folks (since your writing hand is free to actually write). I always assumed the standard arrangement was simply created by some anonymous lefty in an attempt to give them (another) advantage over right-handed folks, and am always baffled when a lefty wants to change it. On to the discussion, asking the user to press the button they usually use for selecting things does work, but adds yet another step and I can see the complaints about it now. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Emacs package guidelines introduce unnecessary deps
MC == Michael Cronenworth m...@cchtml.com writes: MC The guidelines now force any package that has Emacs add-ons to MC install them in the main package and Requires: MC emacs-filesystem. Emacs is not installed by default and I do not use MC Emacs, nor will I ever. emacs-filesystem consists of three directories and nothing else. There's no dependency on emacs itself. MC I'm not sure why having sub-packages was such a negative thing. Can MC we bring back sub-packages? Seems to me that wouldn't bring any real benefit. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 'newpackager' is not in FAS, or How to co-maintain a package before getting sponsored
RL == Robin Lee cheese...@fedoraproject.org writes: RL Hi, all I want to follow the route [1] to bring up a new RL packager. Then why not follow the procedure you referenced? It tells you what to do, which involves opening a ticket in the appropriate trac instance. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide tree structure
MC == Mike Chambers m...@miketc.net writes: MC Did my eyes deceive me, or do the packages now get separated and put MC in their respected dir of their first letter, and not located in one MC dir now? Yes. MC Did the tree change or is this an error? The tree changed. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: filesystem
dp == darrell pfeifer darrel...@gmail.com writes: dp As far as I've seen on the list, the /usr move stuff was supposed to dp be confined by tagging to f17-usermove so it wouldn't affect rawhide dp until the big switch was pulled. Well, yes, but the big switch has actually been pulled. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
PP == Petr Pisar ppi...@redhat.com writes: PP zoneminder Went ahead and rebuilt it now as I intend to be working on it tomorrow. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
SS == Simo Sorce s...@redhat.com writes: SS I guess it is time to change habits, what's the point of a separate SS /usr these days ? I also always configured a separate /usr until I decided to obey systemd's complaints about it being broken (though of course I never had any issue at all with it). For me it was simply keeping / small and being able to back it up easily without backing up all of the stuff in /usr. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Could someone, please, clarify situation with *-javadoc
PL == Peter Lemenkov lemen...@gmail.com writes: PL Sometimes *-javadoc sub-packages explicitly requires main PL package, and sometimes - not. I'm not a java-expert, so I don't know PL which is correct. Java guidelines have come up recently on the packaging list. The templates in the Java packaging guidelines all show the javadoc package with a dependency on the main package. Otherwise, this is not addressed in the guidelines. I would follow the templates, although I will try to get this addressed with the next guideline revision. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled
AH == Alex Hudson fed...@alexhudson.com writes: AH So Red Hat's lawyers know that Red Hat are distributing something AH which they have no license for, so either they haven't passed that AH message on or Red Hat have decided they don't care?* http://en.wikipedia.org/wiki/False_dilemma - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gethostbyname() and resolv.conf updates
BI == Bernie Innocenti ber...@codewiz.org writes: BI A Debian user told me that Debian carries a glibc patch to make BI processes notice resolv.conf updates and reload it. Is there any BI chance we could apply the same patch in Fedora too? I don't know all BI the details, but I guess there might be a good reason why this patch BI wasn't upstreamed yet. Well, it never hurts to search bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=442172 is, I believe, on point. There's also https://bugzilla.redhat.com/show_bug.cgi?id=565880. However, I'm not sure if or how sssd makes any difference here. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
TK == Toshio Kuratomi a.bad...@gmail.com writes: TK * What replaces chkconfig TK * What replaces /etc/init.d/SERVICENAME start | stop ? If the answers aren't chkconfig and service foo start then I fear significant backlash from poor people who actually have to run F-14 systems. We pretty much have to keep them working, even if they have to be packaged separately from systemd. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Q: webfonts:
NM == Nicolas Mailhot nicolas.mail...@laposte.net writes: NM I'm not convinced at all this needs changing, since mod_alias NM permits mapping of system paths anywhere you want in your URL space. But selinux probably doesn't, so the issue is slightly more complicated. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Q: webfonts:
NM == Nicolas Mailhot nicolas.mail...@laposte.net writes: NM I don't think selinux will block web server accesses to NM /usr/share/fonts/something, since we deploy webapps in NM /usr/share/something_else, which is pretty much the same namespace. Well, there are a whole lot of specific fcontext entries for content in /usr/share, including fonts which get their own type (fonts_t). I certainly wouldn't assume that it would simply work, though it would be fairly easy for the policy to adapt if it didn't. My point was simply that there are other configurations besides fix it with mod_alias. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
