devel July 2009

devel@lists.fedoraproject.org

325 participants
343 discussions

upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse 17 Jan '22

17 Jan '22

I have the yarrow's iso files on my HD in a RH9 system. Let's say I want to upgrade selected packages using an "apt-get install" pointing to my iso-mounted files, how do I do it? i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc.. Then what is the complete procedure to make my apt look into my own HD to upgrade packages. Can anybody redirect me to the correct resource or some literature hanging on the web? Thanks. Assume also that I do not wish to burn CDs! I do not want to use apt-cdrom. Thanks. With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg

6 9

kernel/accounting question ...
by William W. Austin 16 Dec '09

16 Dec '09

(I know that this question might be more reasonable on a kernel list, but a while back I posted the question twice and got no answers.) The acct struct is defined in /usr/include/sys/acct.h includes both ac_io and ac_rw for bytes transferred and blocks read or written, respectively. Fair and good - works (on paper) similarly to unix, solaris, hp-ux, etc. However, in the kernel code [kernel/acct.c], ac_io (char) and ac_rw (blocks) are always set to 0 by these two lines: ac.ac_io = encode_comp_t(0 /* current->io_usage */); ac.ac_rw = encode_comp_t(ac.ac_io / 1024); For most purposes, this probably wouldn't be an issue, but I also do extensive performance analysis on several platforms and have written a fairly compresive accounting package (as a wraparound for psacct or as a standalone) including both an improved acctcom and a built-in reporter for it. Does anyone know wby the kernel zero's out the bytes transferred data? (Overhead comes to mind.) Not that it makes a huge differnce for my purposes (I had to write some wraparound code to make a "best-guestimate" about the data I'm missing), but curiosity is bugging me now. When I compile my program on other OS's I get useful data for char and block i/o and I'd like to find out whether there is something obvious that I'm just totally missing here...). Thanks -- william w. austin waustin(a)speakeasy.net "life is just another phase i'm going through. this time, anyway ..."

4 3

acctcom for linux
by William W. Austin 16 Dec '09

16 Dec '09

I recently made several updates to a Linux version of of acctcom (actually another accounting add-on package) which I've been using for several years, and one of the people testing it asked a question which I cannot answer. I'm hoping that someone on this list can give me some info. I have previously (over a year ago) asked on both this and a couple of kernel lists (several times there) about this issue, but nobody has ever answered. So if you have any info about this, I'd really appreciate it. As in many (all?) previous Linux kernels, the struct acct (defined in /usr/include/sys/acct.h) has members ac_io and ac_rw which are presumably counts of characters transferred and blocks read/written respectively. However, in the kernel code, the ac_io is set to 0 and the ac_rw gets set to (ac_io/512) or some such - it is set to 0 as well (and thus these are always reported as 0 in process accounting records. not good if you're trying to measure them...). Does anybody know why this is done that way? A long time ago (IIRC late 2.2 and an early 2.4 kernel) I looked into "fixing" this in the kernel code but was not successful (I finally produced a bootable kernel, but it was unstable. Then I changed jobs, got swamped at work, and eventually gave up). As I said above, I have previously asked about this issue without success, and I have essentially given up changing or "fixing" it. But if anyone knows __WHY__ it is this way (I'm hypothesizing that it's just too much work for too little added value), I'd really appreciate knowing the reason. Curiosity and the cat and all that ... Thanks - Bill -- william w. austin waustin(a)speakeasy.net "life is just another phase i'm going through. this time, anyway ..."

3 2

Need a sponsor: mod_proxy_html (apache)
by Philip Prindeville 11 Dec '09

11 Dec '09

Hi. I need a sponsor for this. An RPM has been built on several systems (including FC8 and FC9 and Centos5) and tested on all of those. The ticket has been languishing now unassigned for almost a year. https://bugzilla.redhat.com/show_bug.cgi?id=452636 Can someone please pick this up? It's just an .src.rpm for Apache's mod_proxy_html. It's pretty trivial. Thanks, -Philip

6 9

Packages looking for new owners
by Trond Danielsen 07 Dec '09

07 Dec '09

Hi everyone, it is becoming clear to me that I can no longer provide the collection of packages I maintain the love and care that they deserve. If only there were more hours in a day, but the current situation does no leave much room for volunteer work on free software :-(. Hopefully I will find time in the future to return to Fedora related work The list if packages I maintain is available here: https://admin.fedoraproject.org/pkgdb/users/packages/trondd?acls=owner I don't mind keeping libopenraw, avrdude and uisp unless anyone _really_ want to maintain these packages. Best regards, -- Trond Danielsen

8 12

Orphaning packages
by Conrad Meyer 30 Oct '09

30 Oct '09

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 <cemeyer(a)u.washington.edu>

2 2

Packaging Survey - May 2009
by Rahul Sundaram 27 Oct '09

27 Oct '09

Hi I did a quick survey from Fedora on what software Fedora users are using that is not available in the repo. Here are the results. If you find anything interesting, feel free to pick it up. https://fedoraproject.org/wiki/Packaging_Survey_May_2009 Rahul

18 32

Possible packages...
by Nathanael D. Noblet 18 Sep '09

18 Sep '09

Hello, So I've been toying with the idea of getting more involved with fedora. Up till now if there has been a bug or other issue, i'll file a bug or simply get the srpm and try to update it to a newer version, or create my own specs / rpms when they don't already exist. Lately I've figured that I should get more involved with some of the packages that I use or anything like that. The packaging guidelines kinda describe entry to the packager group as being done via new packages. I've offered to try to help on some recently orphaned packages. Though that may be more work than just submitting a new package. So after all that rambling, I'm wondering about the two following pieces of software. Apple's Calendar Server. It runs using python 2.5 or greater (I've installed it on a F11 machine and it work well). I've started looking at some of its dependancies. 90% of them are in fedora already, and of the ones in F11, only one if I remember correctly isn't at the version it requires). It seems like a great addition to Fedora if you ask me. So basically it would require two new packages, and an update to one other package (libevent) which is a minor version bump it seems if at all needed. PS3MediaServer. A Java program to talk to a PS3 with DLNA. I'm guessing this one would have problems because it requires ffmpeg or mplayer/mencoder... Plus as a java program its probably a bit more complex to create a proper spec file for. I've made the other kind often enough, but java ones not so much... Any feedback on either?

11 34

xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages
by Braden McDaniel 10 Sep '09

10 Sep '09

Is this as it should be? Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: xulrunner x86_64 1.9.1.1-1.fc11 updates 9.5 M Installing for dependencies: GConf2 i586 2.26.2-1.fc11 updates 1.7 M ORBit2 i586 2.14.17-1.fc11 fedora 186 k PolicyKit i586 0.9-6.fc11 fedora 165 k alsa-lib i586 1.0.20-1.fc11 fedora 419 k atk i586 1.25.2-2.fc11 fedora 222 k audit-libs i586 1.7.13-1.fc11 updates 83 k avahi i586 0.6.25-3.fc11 updates 292 k avahi-glib i586 0.6.25-3.fc11 updates 19 k bzip2-libs i586 1.0.5-5.fc11 fedora 39 k cairo i586 1.8.8-1.fc11 updates 514 k cracklib i586 2.8.13-4 fedora 50 k cups-libs i586 1:1.4-0.b2.18.fc11 fedora 341 k cyrus-sasl-lib i586 2.1.22-22.fc11 fedora 145 k db4 i586 4.7.25-11.fc11 fedora 669 k dbus-glib i586 0.80-2.fc11 fedora 178 k dbus-libs i586 1:1.2.12-2.fc11 updates 132 k e2fsprogs-libs i586 1.41.4-10.fc11 fedora 154 k expat i586 2.0.1-6 fedora 86 k fontconfig i586 2.6.99.behdad.20090508-1.fc11 fedora 203 k freetype i586 2.3.9-3.fc11 fedora 388 k gamin i586 0.1.10-4.fc11 fedora 134 k glib2 i586 2.20.4-1.fc11 updates 1.5 M glibc i686 2.10.1-2 fedora 5.8 M gnome-vfs2 i586 2.24.1-2.fc11 fedora 947 k gnutls i586 2.6.6-1.fc11 fedora 379 k gtk2 i586 2.16.2-1.fc11 updates 4.3 M hal-libs i586 0.5.12-26.20090226git.fc11 fedora 70 k jasper-libs i586 1.900.1-10.fc11 fedora 155 k keyutils-libs i586 1.2-5.fc11 fedora 19 k krb5-libs i586 1.6.3-20.fc11 fedora 705 k libICE i586 1.0.4-7.fc11 fedora 55 k libIDL i586 0.8.13-1.fc11 fedora 89 k libSM i586 1.1.0-4.fc11 fedora 27 k libX11 i586 1.2.1-2.fc11 updates 1.0 M libXau i586 1.0.4-5.fc11 fedora 21 k libXcomposite i586 0.4.0-7.fc11 fedora 16 k libXcursor i586 1.1.9-4.fc11 fedora 30 k libXdamage i586 1.1.1-6.fc11 fedora 12 k libXext i586 1.0.99.1-2.fc11 fedora 35 k libXfixes i586 4.0.3-5.fc11 fedora 16 k libXft i586 2.1.13-2.fc11 fedora 52 k libXi i586 1.2.1-1.fc11 fedora 32 k libXinerama i586 1.0.3-4.fc11 fedora 14 k libXrandr i586 1.2.99.4-3.fc11 fedora 31 k libXrender i586 0.9.4-5.fc11 fedora 30 k libXt i586 1.0.5-2.fc11 fedora 182 k libacl i586 2.2.47-4.fc11 fedora 24 k libattr i586 2.4.43-3.fc11 fedora 15 k libbonobo i586 2.24.1-1.fc11 fedora 487 k libcap i586 2.16-4.fc11.1 updates 32 k libdaemon i586 0.13-2.fc11 fedora 28 k libgcc i586 4.4.0-4 fedora 94 k libgcrypt i586 1.4.4-6.fc11 updates 234 k libgnome i586 2.26.0-1.fc11 fedora 732 k libgpg-error i586 1.6-3 fedora 66 k libjpeg i586 6b-45.fc11 fedora 145 k libpng i586 2:1.2.37-1.fc11 updates 256 k libselinux i586 2.0.80-1.fc11 fedora 107 k libstdc++ i586 4.4.0-4 fedora 323 k libtasn1 i586 1.8-2.fc11 fedora 302 k libthai i586 0.1.9-7.fc11 fedora 189 k libtiff i586 3.8.2-14.fc11 updates 309 k libxcb i586 1.2-4.fc11 updates 131 k libxml2 i586 2.7.3-2.fc11 fedora 855 k ncurses-libs i586 5.7-2.20090207.fc11 fedora 334 k nspr i586 4.8-1.fc11 updates 123 k nss i586 3.12.3.99.3-2.11.3.fc11 updates 1.0 M nss-softokn-freebl i586 3.12.3.99.3-2.11.3.fc11 updates 136 k openldap i586 2.4.15-3.fc11 fedora 338 k openssl i686 0.9.8k-5.fc11 updates 1.4 M pam i586 1.0.91-6.fc11 fedora 767 k pango i586 1.24.4-1.fc11 updates 400 k pixman i586 0.14.0-2.fc11 fedora 123 k popt i586 1.13-5.fc11 fedora 41 k python-libs i586 2.6-9.fc11 updates 663 k readline i586 5.2-14.fc11 fedora 187 k sqlite i586 3.6.12-3.fc11 fedora 322 k xulrunner i586 1.9.1-0.20.beta4.fc11 fedora 10 M zlib i586 1.2.3-22.fc11 fedora 75 k Updating for dependencies: cairo x86_64 1.8.8-1.fc11 updates 506 k cairo-devel x86_64 1.8.8-1.fc11 updates 185 k dbus x86_64 1:1.2.12-2.fc11 updates 234 k dbus-devel x86_64 1:1.2.12-2.fc11 updates 45 k dbus-libs x86_64 1:1.2.12-2.fc11 updates 133 k dbus-x11 x86_64 1:1.2.12-2.fc11 updates 39 k epiphany x86_64 2.26.3-1.fc11 updates 4.9 M epiphany-extensions x86_64 2.26.1-4.fc11 updates 1.0 M glib2 x86_64 2.20.4-1.fc11 updates 1.6 M glib2-devel x86_64 2.20.4-1.fc11 updates 1.3 M pango x86_64 1.24.4-1.fc11 updates 407 k pango-devel x86_64 1.24.4-1.fc11 updates 321 k xulrunner-devel x86_64 1.9.1.1-1.fc11 updates 3.9 M Transaction Summary ================================================================================ Install 79 Package(s) Update 14 Package(s) Remove 0 Package(s) -- Braden McDaniel <braden(a)endoframe.com>

5 15

FESCo meeting summary for 20090729
by Jon Stanley 23 Aug '09

23 Aug '09

Sorry for the delay in getting this out, I was distracted right at the end of the meeting by a coworker hovering over my desk :). Summary: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-29/fedora-meeting.2… Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-29/fedora-meeting.2… Note that the vote on VirtTCK was not unanimous, somehow that didn't make it into the summary but was something that we wanted to call out. ---- 17:01:20 <jds2001> #startmeeting FESCo special meeting - 2009-07-29 17:01:24 <jds2001> #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:01:28 * onekopaka will be here. 17:01:41 * skvidal is here 17:01:44 * cwickert is also here as Christoph Wickert 17:01:44 * notting is here 17:01:47 * nirik is here. 17:01:49 <Kevin_Kofler> Present. 17:01:54 * sharkcz is here 17:01:56 <Kevin_Kofler> onekopaka: Yeah, but you can't vote. ^^ 17:01:58 * jds2001 brings up the list 17:02:02 <onekopaka> Jeff_S: I know! 17:02:07 <onekopaka> err 17:02:10 <onekopaka> Kevin_Kofler: I know! 17:02:10 <Gerd> Gerd is also here as Gerd Pokorra 17:02:22 * Jeff_S can't vote either 17:02:24 * onekopaka will be here for the fun of it. 17:02:31 * dgilmore is here 17:02:39 <dgilmore> but im in another meeting also 17:02:42 <onekopaka> because it's fun to watch these meetings. 17:02:45 <onekopaka> FUN. 17:02:50 <jds2001> anyhow 17:02:51 <jds2001> ;et 17:02:54 <jds2001> let 17:02:59 <jds2001> 's get started 17:03:05 <jds2001> i cant type today 17:03:13 <jds2001> #topic Raduko perl 6 17:03:16 * skvidal gives jds2001 a new 300 baud acoustic coupler to use 17:03:18 <jds2001> .fesco 218 17:03:29 <cwickert> can I say something about this? 17:03:31 <onekopaka> perl 6? 17:03:35 <jds2001> sure 17:03:43 <cwickert> first of all I feel like people who voted were not really informed 17:03:50 <dgilmore> -1 17:03:53 <cwickert> somebody claimed we were still waiting for something. 17:03:57 <Kevin_Kofler> +1, seems they can get it in, and if not it can always be punted later. 17:03:58 <cwickert> this is not correct. the 'something" was released three days before. 17:04:06 <cwickert> we have a building package now 17:04:07 <dgilmore> this feature is 33% done and feature freeze is past 17:04:10 <jds2001> right, we didnt think you had a working interpreter at all. 17:04:17 <jds2001> but now you do :) 17:04:23 <skvidal> cwickert: fortunately we don't have to be informed to vote - it's just like the american electorate :) 17:04:26 <Kevin_Kofler> I think we should approve this. 17:04:31 <cwickert> skvidal: ;) 17:04:32 <Kevin_Kofler> It's a new package, it can't break anything. 17:04:52 <cwickert> dgilmore: the feature does not need to be at 100% for feature freeze 17:04:56 <Kevin_Kofler> So even if it gets completed a few days late due to upstream scheduling, that won't affect Fedora in any negative way. 17:05:12 <cwickert> we did it in a couple of days, so please let us try 17:05:22 <Kevin_Kofler> And if it really fails, we can always postpone it to F13 later. 17:05:44 <cwickert> Kevin_Kofler: we are in contact with upstream, at least Gerd works with them closely 17:05:45 * jds2001 says to let them try 17:05:58 * onekopaka would say +1. 17:05:59 <nirik> is someone planning on reviewing that package? it's still in new. ;) 17:06:03 <dgilmore> cwickert: it should be very close 17:06:12 <skvidal> so I'm confused 17:06:19 <Kevin_Kofler> dgilmore: It's a new package, it can't break anything. 17:06:20 <cwickert> nirik: I will and I think lubomir will too 17:06:21 <Kevin_Kofler> It can go in late. 17:06:37 <skvidal> cwickert: if we don't approve this as a feature - how does it stop you from working on it? 17:06:38 <dgilmore> Kevin_Kofler: doesnt matter 17:06:41 <Kevin_Kofler> I'm sure rel-eng can let it in. 17:06:56 <cwickert> skvidal: nothing, but Fedora won't benefit then 17:06:56 <dgilmore> skvidal: it doesnt 17:06:58 <nirik> skvidal: it doesn't, it just doesn't get advertised. 17:07:05 <nirik> (or as much) 17:07:07 <Kevin_Kofler> dgilmore: Freeze exemptions have been granted for new packages in several cases. 17:07:10 <skvidal> cwickert: fedora benefits from it how? 17:07:15 <Kevin_Kofler> The rationale is: it can't hurt. 17:07:32 <Kevin_Kofler> skvidal: It supports a new language which is going to be the next big thing in the Perl community. 17:07:38 <cwickert> if we have a working perl6 binary, fedora can be used by teachers to show their students the future of perl 17:07:46 <Kevin_Kofler> Maybe KDE 5 or even some later 4.x will even require it. 17:07:48 <cwickert> we could hae it in the devel spin as well 17:08:04 <Kevin_Kofler> (Current KDE requires Perl 5 for some things, e.g. kconf_update and some build-time scripts.) 17:08:08 <cwickert> Fedora will be a better platform for developers 17:08:13 * nirik looks at the feature freeze page. 17:08:14 <skvidal> cwickert: again 17:08:18 <skvidal> nothing says it can't get it 17:08:21 <skvidal> just that it is not a feature 17:08:26 <skvidal> see what I mean? 17:08:30 <Kevin_Kofler> skvidal: Why is it not a feature? 17:08:37 <skvidal> if we don't approve it 17:08:38 <Kevin_Kofler> Just because it gets in a few days late? 17:08:41 <Kevin_Kofler> That's ridiculous. 17:08:42 <cwickert> skvidal: yes I d, but I think I lined all this out on the featrure page 17:08:44 <notting> the issue i have is not that it's not 100% done; it's not even testable at all 17:08:48 <nirik> "All features must be complete in a testable state" 17:09:05 <Kevin_Kofler> notting: I'm sure it can be snuck into the alpha. 17:09:11 <cwickert> nirik: good catch 17:09:14 <jds2001> they've demonstrated that it's testable, they have a perl6 working 17:09:17 <Kevin_Kofler> The extra time between the freeze and the alpha is just to avoid anything which breaks spins. 17:09:22 <jds2001> it can say hello world right now 17:09:26 <Kevin_Kofler> A new package can't break anything. 17:09:32 <dgilmore> jds2001: its not testable packages are not in fedora 17:09:33 <skvidal> Kevin_Kofler: yes, it really can 17:09:33 <nirik> Kevin_Kofler: not entirely true 17:09:53 <Kevin_Kofler> Yeah, of course if it Obsoletes: glibc, it can break something. ^^ 17:09:53 <notting> jds2001: if testable means 'testable by the QA group', i don't want that to involve 'build it yourself' 17:09:55 <cwickert> is fedora Studio testable? no, they donÄt have a spin 17:09:58 <Kevin_Kofler> But in practice, it can't break anything. 17:10:10 <jds2001> notting: correct, i thought it was already in rawhide 17:10:22 <nirik> jds2001: it's not past review yet 17:10:22 <jds2001> if not, then this needs to be deferred. 17:10:30 <cwickert> or is moblin testable? this requires much more reviews, but it's approved 17:10:30 <jds2001> ok, i was mistaken. 17:10:57 <Kevin_Kofler> Can't we give them a few more days (assuming rel-eng buyin)? 17:11:11 <jds2001> unfortuantely not 17:11:18 <notting> cwickert: then it will likely get yanked. the earlier the feature comes in, the more lenient we can be in getting time to get it finished 17:11:24 <Kevin_Kofler> The upstream release of parrot they needed was only a few days before the freeze. 17:11:28 <dgilmore> cwickert: if its not testable it will be on the table to be dropped 17:11:31 <Kevin_Kofler> jds2001: And why not? Because you say so? 17:11:54 <jds2001> we've been soft in the past, and it's bitten us 17:11:57 <nirik> yeah, I suspect moblin won't make it... :( 17:12:04 <notting> there still isn't a link in the review page to a package that actually builds. (last update as of monday) 17:12:11 <Kevin_Kofler> +1 to the feature and -1 to pointless pedantic bureaucracy which will just hurt our PR. 17:12:13 <cwickert> dgilmore: ok, then please drop all other features that are not testable today, and please don't forget to explain this to their owners, who have put much work into it. 17:12:23 <Kevin_Kofler> Because it means the package will end up in F12 anyway, but not be eligible as a feature. 17:12:36 <Kevin_Kofler> Either it'll get advertised as a "F13 feature" when it's really a F12 one. 17:12:45 <Kevin_Kofler> Or it'll get rejected outright and we lose. 17:13:17 <cwickert> ok, time to vore I guess. or does anybody have something he wants to add? 17:13:37 <nirik> should we just not have deadlines at all is what you are saying? 17:13:48 <Kevin_Kofler> We should have flexible deadlines. 17:14:20 <Kevin_Kofler> What really counts is that the feature is ready when the last RC (the one which gets the "gold approval" and becomes the GA) is cut. 17:14:38 <Kevin_Kofler> Everything else is just a means to get there and should be flexible. 17:14:38 <cwickert> nirik: sure we should have dealines, but for me the deadline is alpha freeze. if the package does not make it into alpha, let's drop the feature 17:14:44 <jds2001> if that's what you want propose that for the F13 schedule. 17:15:04 <Kevin_Kofler> It's just common sense, really. 17:15:20 <skvidal> Kevin_Kofler: I've found common sense is almost always neither 17:15:23 <f13> We moved the feature freeze back from the alpha freeze 17:15:40 <f13> because I was really fucking tired of people crash landing shit at the alpha freeze, and me having to clean it up before we could do a clean compose 17:15:44 <dgilmore> cwickert: that is not correct 17:15:49 <jds2001> f13: the proposal now is to make feature freeze GA! 17:15:51 <f13> freezes should happen when we're ready, not so that we can spend time to get ready 17:16:01 <f13> jds2001: hell no 17:16:04 <Kevin_Kofler> The proposal is to be flexible. 17:16:11 <jds2001> f13: you and I are together on this :) 17:16:15 <cwickert> dgilmore: elaborate please! 17:16:27 <Kevin_Kofler> We should have a feature freeze, but should we allow exceptions if they're doable on time. 17:16:38 <dgilmore> cwickert: you dont have until alpha to land it you have until feature freeze 17:16:42 <jds2001> on time == freature freeze. 17:17:04 <jds2001> we have that for a reason. 17:17:08 <Kevin_Kofler> f13: For example, in this case, how is that new package going to screw up your composes if it lands in the time between feature freeze and alpha freeze? 17:17:10 <cwickert> dgilmore: the feature freeze is for the feature itself, not the package IMO 17:17:12 <jds2001> and it's not our health. 17:17:29 <Kevin_Kofler> It's not going to touch any existing package (except possible parrot - cwickert: did that go in already?). 17:17:34 * nirik thinks the deadlines make sense, but in this case it's worth considering an exception... it's unclear if it's really that close to being ready though. 17:17:44 <cwickert> Kevin_Kofler: of course 17:17:57 <cwickert> Gerd did the package in less than a week, so I think we can do it. trust us 17:17:57 <nirik> cwickert: when do you see this package as being approved and imported? 17:18:01 <Kevin_Kofler> OK, so it's not going to touch any existing package, just a new one. 17:18:10 <f13> and what's this package? 17:18:11 <cwickert> nirik: depends on the review process 17:18:17 <Kevin_Kofler> f13: rakudo 17:18:18 <cwickert> f13: pardon? 17:18:20 <Kevin_Kofler> An implementation of Perl 6. 17:18:29 <nirik> (noting that there is no buildable link in the review bug and it's in NEW. ;) 17:18:36 <dgilmore> cwickert: but your wrong the featurefreeze is to land things. its when features need to be testable in Fedora itself 17:18:42 <cwickert> f13: did you just say you have no idea what we are talking about? ;) 17:18:44 <f13> and it doesn't introduce any scary Provides/Requires that may screw up package ordering, size on media, etc...? 17:18:49 <cwickert> no 17:18:58 <f13> cwickert: yes, I noticed the tab due to talk about punting to F13 17:19:01 <cwickert> it's not suppsed to be n the media 17:19:16 <f13> and then saw suggestionst hat we move feature freeze to GA 17:19:34 <cwickert> it just buildrequires parrot, which is in Fedora >= 10 17:19:38 <cwickert> nothing more 17:20:00 <dgilmore> f13: i do think we need to move feature submission freeze a month before feature freeze 17:20:03 <nirik> right, so it's a somewhat min change. 17:20:21 <f13> cwickert: and you can't manage to get a pre-release built today? 17:20:22 <Kevin_Kofler> dgilmore: FWIW, that's how KDE works. 17:20:26 <jds2001> dgilmore: that makes sense 17:20:35 <Kevin_Kofler> They have a "soft feature freeze" which is what you call "feature submission freeze". 17:20:38 <cwickert> f13: ask Gerd please 17:20:41 <notting> f13: there is no working buildable package in the review ticket 17:20:44 <Kevin_Kofler> And a "hard feature freeze" which is what you call "feature freeze". 17:20:45 <cwickert> Gerd: ? 17:21:10 <Kevin_Kofler> I'm not sure I like that idea though. The experience I got from KDE is that it encourages overpromising. 17:21:22 <cwickert> dgilmore: repeating myself. I undestand your point of view, but I think it's wrong 17:21:30 <cwickert> please drop all other features that are not testable today, and please don't forget to explain this to their owners, who have put much work into it. 17:21:31 <Kevin_Kofler> You don't know yet whether you can get a feature done, so you declare it just in case and have them punt it later. 17:21:45 <cwickert> drop Gnome 2.28, itÄs not released, so not testable 17:22:04 <jds2001> but it is testable 17:22:14 <jds2001> we have pre-release built all the time 17:22:24 * nirik thinks we are getting sidetracked... 17:22:27 <dgilmore> what jds2001 said 17:22:32 <dgilmore> notting: i agree 17:22:36 * cwickert agrees to nirik 17:22:39 <notting> cwickert: don't be ridiculous 17:22:47 <Kevin_Kofler> (It's even tougher in KDE though because they don't allow features in after the soft freeze which aren't declared in the feature list. In Fedora, you can get away with doing a lot of stuff as long as you don't declare it as a Feature.) 17:22:51 <cwickert> so lets just vote please, gentleman 17:23:00 <dgilmore> i stand by my -1 vote. i dont think that this can be a F-12 feature. 17:23:24 <notting> Kevin_Kofler: that 'don't know yet' is what you're suggesting we do now *AFTER* feature freeze. 17:23:52 <skvidal> before we take a vote 17:23:55 <skvidal> I'd like to say something 17:24:01 <nirik> cwickert: what timezone is Gerd in? 17:24:01 <skvidal> for EVERYONE here 17:24:13 <skvidal> 1. please stop the snarky and snide responses 17:24:16 <cwickert> nirik: UTC+2, just like me 17:24:25 <Kevin_Kofler> notting: I'm pretty sure this package can pass review quickly (they have 2+ people, so one submitter, one reviewer, my experience is that reviews get done fast in those cases). 17:24:33 <cwickert> nirik: so he is no longer in the office I think 17:24:35 <skvidal> 2. please stop using complying with the rules we have as a threat 17:24:42 <notting> nirik: he said he was here at the meeting's beginning 17:24:43 <skvidal> 3. please stop acting like asses to each other. 17:24:44 <Kevin_Kofler> And then getting the feature in is just as simple as building the package in Rawhide. 17:24:52 <cwickert> skvidal: +1 17:24:53 <f13> skvidal: thank you! 17:25:05 <nirik> skvidal: totally agreed. 17:25:07 <Kevin_Kofler> (or worst case with a freeze override) 17:25:12 <skvidal> cwickert: number 2 was addressed to you in particular 17:25:32 <f13> my suggestion would be to vote it as not a feature now, since it isn't ready. 17:25:44 <f13> if it becomes ready in the next few days, re-visit the issue once there is a built and testable package on hand. 17:25:56 <cwickert> skvidal: understood. but it seems like the rules are different for different features 17:25:57 * jds2001 is +1, if the package doesn't make it by alpha, we can punt to F13. 17:26:17 <f13> cwickert: you make that claim, but where is the evidence? 17:26:25 <jds2001> f13: I'm of the same opinion, but default accept UNLESS there's not a built and testable package on hand. 17:26:27 <cwickert> f13: http://fedoraproject.org/wiki/Releases/12/FeatureList 17:26:32 <nirik> I am +1 if it lands very very soon. It needs reviewed and added asap. If it's not, punt to next release. 17:26:34 <skvidal> cwickert: I think the rules are bent with the relative importance of the feature, no doubt 17:26:56 <skvidal> cwickert: and I don't think that should be otherwise - flexibility has its benefits - but we cannot ALWAYS be flexible 17:26:58 <f13> cwickert: please be a bit more specific. 17:27:04 <skvidal> f13: let's not do this here, okay? 17:27:08 <sharkcz> +1, same opinion as nirik 17:27:11 <f13> sure. 17:27:18 <cwickert> skvidal: but the feature is not important, it can't break anythink, so no need to apply the rules so strictly 17:27:30 <skvidal> cwickert: that's why we vote 17:27:45 <Kevin_Kofler> I stand by my +1. 17:27:50 * f13 wonders if it's not important, why is it a Feature? 17:27:56 <notting> *cough* if it's not important, it shouldn't be a Feature. i'm assuming that's not what you meant. 17:28:06 * dgilmore says -1 17:28:17 <cwickert> f13: there are features in the page and that are behind us, that are not testable ether, but that are appoved 17:28:18 <jds2001> this is getting really old really fast. 17:28:28 <jds2001> we have 3 +1, 2 -1 thus far 17:28:51 <Kevin_Kofler> I think the point is that it is important to advertise, but not critical for the distro. 17:28:58 <notting> jds2001: i saw 4 +1, 1 -1 17:29:05 <cwickert> thanks 17:29:30 <cwickert> f13: who say's it's not important? it's not important do you as rel-eng, but it's important for others 17:29:47 <jds2001> notting: youre right, im on some good stuff apparently :) 17:29:51 <skvidal> cwickert: you said it wasn't important 17:30:06 <skvidal> "[13:25] <cwickert> skvidal: but the feature is not important, it can't break anythink," 17:30:08 <cwickert> skvidal: important depends on the pov. 17:30:22 <cwickert> not important for distro composition etc 17:30:45 <cwickert> anyway, thanks everybody for the time discussing this 17:30:52 <f13> cwickert: any brand new rushed package can have disastrous impact upon composing. 17:30:58 <Kevin_Kofler> Grrr, we already spent 30 minutes on debating this one feature and we still don't have an outcome. 17:31:11 <Kevin_Kofler> Anybody who dares giving the 5th +1 vote? :-) 17:31:20 <f13> there is a reason why I strongly push to have things land a week before we freeze so that we can catch the gotchas before they turn into a release slip 17:31:40 <f13> people don't like long freezes, so we have to land things before we freeze so that we can get /out/ of the freeze ASAP 17:31:42 <cwickert> f13: how would this cause a slip? 17:31:42 <Gerd> +1 17:31:55 <Kevin_Kofler> Gerd: :-) Too bad your +1 does not count... 17:31:56 <nirik> Gerd: nice try. :) 17:32:02 <cwickert> Gerd: we are not allowed to vote ;) 17:32:05 <f13> cwickert: an overlooked provides clash 17:32:11 * nirik wonders where the rest of fesco is... please vote so we can move on? 17:32:18 <skvidal> f13: or an auto-provides :( 17:32:23 <f13> yep 17:32:33 <f13> both have caused major issues in the past 17:32:37 <cwickert> skvidal: this should be catched in alpha and beta 17:32:38 <jds2001> we've spent 30 minutes on this feature..... 17:32:43 <Kevin_Kofler> Hmmm, I do see the risk there, especially clashes with Perl 5. 17:32:56 <f13> cwickert: it should be caught /before/ we freeze for Alpha 17:33:03 <f13> so that it doesn't cause alpha to slip 17:33:13 <skvidal> -1 - I do not think this needs to be a feature in order to be advertised to a specific subset of our users who will use perl. I think it should come in as a package and be tested normally, though. 17:33:27 <cwickert> 4:2 then 17:33:43 <Kevin_Kofler> 3 FESCo members have not voted yet. 17:33:48 <notting> does the vote have to be +1/-1? i am ok with a "+1, should land by friday", as i don't want it to land right at the package freeze 17:34:14 <skvidal> notting: I think a provisional +1 is reasonable 17:34:18 <cwickert> notting: you mean in the repo by Friday? 17:34:18 <jds2001> notting: the vote can be that 17:34:23 <jds2001> cwickert: yep 17:34:30 <cwickert> this is hard.. 17:34:58 <notting> cwickert: 'reviewed by' 17:35:03 <cwickert> ok 17:35:20 <f13> (this is why I recommended defaulting to voting it not a feature, and re-convening should the package make it in time to discuss reversing that vote) 17:35:53 <jds2001> we can punt this to friday and see if anything changes. 17:35:58 <jds2001> im fine with that. 17:36:10 <cwickert> where are the 3 fesco members who haven't voted? 17:36:11 <jds2001> all in favor? 17:36:20 <jds2001> cwickert: un-here :) 17:36:31 <nirik> well, with nottings provisional +1, it's approved right? 17:36:44 <Gerd> I will try to hold the timetable by Friday 17:36:54 <jds2001> yeah, i'd still like to revisit on Friday 17:37:00 <Kevin_Kofler> Let's do that. 17:37:12 <nirik> Gerd: you have a buildable package, right? you should update the review bug with a link asap. ;) 17:37:29 <cwickert> Gerd: this is addressed to you 17:37:36 <jds2001> #agreed Raduko Perl 6 feature is approved, providing the pakcage review is approved by Friday 7/31/09 17:37:53 <jds2001> #topic System crypto database 17:37:53 <dgilmore> jds2001: thats fine 17:38:00 <jds2001> .fesco 219 17:38:56 <notting> -1 . this doesn't look done yet, and it's an API other packages would have to buy into 17:39:00 <dgilmore> -1 17:39:13 <notting> (it's a fine idea) 17:39:22 <dgilmore> looks like the work to get it testable is still a ways off 17:39:25 <nirik> -1 here as well... it doesn't seem testable, and will require coordination with other packages. 17:39:35 <dgilmore> notting: i agree and f13 will love it 17:39:48 <jds2001> -1 for that reason too, actually 17:39:53 <sharkcz> -1, but the idea is right 17:39:57 <Kevin_Kofler> Hmmm, I'd +1 this in principle, but if no apps are actually using it, it doesn't look that great. 17:39:57 <skvidal> -1 as well, worried how badly this could break a lot of things 17:39:58 * jds2001 thought it was a fine idea as well. 17:40:15 <jds2001> that's why i was +1 in email :) 17:40:44 <jds2001> im not sure how badly it could break things, though - it looks like the API is new 17:40:57 <notting> jds2001: advertising an API nothing is using isn't particularly useful 17:41:00 <jds2001> or does it change the behavior of existing API's 17:41:08 <jds2001> notting: agreed :) 17:41:30 <Kevin_Kofler> Same here. 17:41:31 <jds2001> anyhow 17:42:04 <Kevin_Kofler> That said, weren't the SystemTap improvements the same - new APIs, but no apps using them yet? 17:42:13 <Kevin_Kofler> That said, SystemTap is a developer tool, it's kinda different. 17:42:14 <jds2001> #agreed System Crypto Database is declined for F12 due to nothing using the new API's. 17:42:23 <Kevin_Kofler> This here is an end user library, but no users yet. 17:42:25 <jds2001> Kevin_Kofler: it is a developer tool, you use the API's yourself :) 17:42:34 <Kevin_Kofler> Yeah. :-) 17:42:47 <notting> Kevin_Kofler: systemtap APIs were also done, as i recall 17:42:49 <Kevin_Kofler> So -1, this needs to be implemented distro-wide kinda like FeatureDictionary was. 17:43:02 <jds2001> #topic Virt TCK 17:43:37 <Kevin_Kofler> Same as last week: -1, not a feature, just an internal process improvement. 17:43:42 <jds2001> so has anyone's opinions on this changed, or are we in for another deadlock? 17:44:04 <notting> if nothing has changed with the page, feature itself, can we table it until the end? 17:44:35 <jds2001> sure 17:44:37 <Kevin_Kofler> I propose we just ask the people who didn't vote last Friday to express their vote. 17:44:49 <Kevin_Kofler> At least dgilmore is here now, I forgot who was the other non-voter. 17:45:32 <jds2001> #topic media repo 17:45:38 <jds2001> .fesco 226 17:45:47 <jds2001> I se this as both good and bad. 17:46:20 <nirik> does this have buy in from the various maintainers? is it testable now? (seeing 50%) there 17:46:32 <jds2001> there are screenshots there. 17:46:53 <Kevin_Kofler> This appears to be implemented even in KPackageKit, that's nice for a change! 17:47:01 <Kevin_Kofler> Finally somebody who cares about KDE. 17:47:18 <Kevin_Kofler> +1 to this feature, it's useful and it's being implemented in gnome-packagekit, KPackageKit and even Yumex! 17:47:59 <dgilmore> -1 its not testable, and its not clear whats done or left to be done. I think the idea is good. 17:48:19 <dgilmore> without enough data to know if its really actually close i cant give it a +1 17:48:24 <nirik> I would be ok with it, but it's unclear to me if it's already in or not. 17:48:33 <notting> it doesn't appear testable - there's no link to the patches/packages. also, it brings in a hal dependency where there wasn't one before 17:48:35 <nirik> and has buyin from the maintainers, etc. 17:48:42 <notting> so, -1 from me 17:49:21 <skvidal> can we defer this one until friday? I ask b/c Alsadi has updated all his patches and I've seen the posts to the upstreams 17:49:30 <nirik> yeah, -1 here, but the idea is good. Persure for next cycle and/or ask for a late vote if it's really already in and testable and the page doesn't let us know that. 17:49:33 <skvidal> I'd lik to make sure he's updated the page 17:49:35 <skvidal> however 17:49:41 <skvidal> if not - then I'm fine w/it not being a feature 17:49:51 <dgilmore> skvidal: that seems fine 17:50:01 <nirik> yeah, seems fine to me. 17:50:12 <Kevin_Kofler> The usefulness is limited due to how the packages from the media are very often outdated in Fedora land. 17:50:16 <jds2001> seems fine 17:50:19 <dgilmore> skvidal: though the page was last edited yesterday 17:50:21 <Kevin_Kofler> But still, it can save bandwidth. 17:50:26 <jds2001> Kevin_Kofler: that was my thing on the ML 17:50:42 <nirik> in some places it would be very handy... 17:50:43 <skvidal> Kevin_Kofler: and nothing is stopping it from landing anyway 17:50:51 <jds2001> i think it's use should be discouraged, but it's handy 17:50:51 <skvidal> and if/when it does land 17:50:53 * f13 wonders what the point of a feature freeze is if we keep punting things to 3 days after the feature freeze 17:50:56 <skvidal> then popping the disk is will just work 17:51:09 <skvidal> f13: it seems like we have enough -1's to say 'no' to it 17:51:14 <skvidal> so nevermind 17:51:45 <jds2001> #agreed media repo feature is declined for F12 17:51:46 <f13> sorry, I'm being snarky :/ 17:52:19 <jds2001> f13: no worries 17:52:38 <jds2001> #topic Split Softokn off from NSS 17:52:48 <jds2001> .fesco 227 17:52:55 <jds2001> so im not sure what this is. 17:52:57 <Kevin_Kofler> Uh, I see only 3 -1 votes for Media Repo. 17:53:10 <jds2001> Kevin_Kofler: out of six here 17:53:38 <jds2001> 6-3 = 3, 5 needed to pass. 17:53:39 <nirik> so is this feature a feature? 17:53:45 <jds2001> thus passage is impossible. 17:53:50 <jds2001> nirik: i dont think so 17:54:05 <nirik> it seems like a reorg of packages that most people won't care about... 17:54:15 <notting> yeah, -1, not a feature. go ahead, though. 17:54:23 <jds2001> -1, this doesnt seem like a feature. 17:54:34 <sharkcz> -1 17:54:41 <nirik> yeah, -1. I suspect no fedora user cares about FIPS either. ;) 17:54:45 <Kevin_Kofler> Yeah, -1, the one sentence should go into the Release Notes, but that's not a feature at all. 17:54:46 <skvidal> -1 not a feature 17:55:17 <jds2001> #agreed Split Softokn off from NSS is not a feature, just a package reorg. 17:55:19 <Kevin_Kofler> If I filed a feature each time we split a subpackage from a KDE package, KDE would have more features than virtualization. ^^ 17:55:35 <jds2001> #topic stap eclipse gui 17:55:40 <jds2001> Kevin_Kofler: :D 17:55:48 <jds2001> .fesco 228 17:56:14 <jds2001> oops, we lost notting 17:57:19 <Kevin_Kofler> +1 to this in principle, but I have some questions: 17:57:33 <Kevin_Kofler> "Users will need to be part of the stapdev group on their machine in order to fully take advantage of SystemTap's offerings." - do we really want to still rely on groups for these things these days? 17:57:44 <Kevin_Kofler> This sounds like the lamest method for access control. 17:58:06 <Kevin_Kofler> Plus, why is there no documentation yet and when will it be written? 17:58:27 <jds2001> Kevin_Kofler: this is how stap today works 17:58:29 <jds2001> i think 17:58:44 <jds2001> at least last time i used it, which was awhile ago. 17:58:59 <Kevin_Kofler> Yeah, I guess it's out of the scope of this feature. But this also means that the Release Notes section needs to be more relevant to the actual feature. ;-) 17:59:21 <dgilmore> +1, though there is very little information in the feature page. at 90% done it should be testable 17:59:31 <jds2001> +1 17:59:37 <nirik> +1 here, but yes, needs docs/update 17:59:48 <notting> +1 17:59:52 <sharkcz> +1 17:59:57 <skvidal> looks like it passes 18:00:11 <jds2001> #agreed SystemTap eclipse gui feature is approved for F12, please update docs 18:00:32 <jds2001> #topic thusnelda 18:00:41 <jds2001> .fesco 229 18:00:45 <Kevin_Kofler> +1, this is great. 18:00:49 <nirik> +1 here on this. 18:01:11 <sharkcz> +1 18:01:17 <jds2001> +1 18:01:32 <notting> +1 18:01:34 <jds2001> #agreed Thusnelda feature is approved 18:01:50 <jds2001> #topic volume control continued 18:01:57 <jds2001> .fesco 230 18:02:07 <Kevin_Kofler> +1, makes the GNOME volume control suck less (but still suck ;-) ). 18:02:14 <Kevin_Kofler> But IMHO it should be called GnomeVolumeControlContinued. 18:02:22 <jds2001> +1 18:02:27 <nirik> +1 18:02:29 <skvidal> Kevin_Kofler: what did I say about being snarky and an ass? 18:02:29 <sharkcz> +1 18:02:33 <skvidal> Kevin_Kofler: knock it off 18:02:44 <notting> +1, it's better, and it's testable (even on f11, with effort) 18:02:50 <skvidal> +1 to the feature 18:03:05 <dgilmore> +1 18:03:07 <jds2001> #agreed Volume Control Continued feature is accepted 18:03:15 <jds2001> #topic Harfbuzz 18:03:21 <jds2001> .fesco 231 18:03:32 <Kevin_Kofler> As long as gnome-volume-control will not talk directly to ALSA for advanced settings and as long as PA will continue to hide settings like CD (the direct cable) or PC Speaker, it will never be able to fulfill all usecases. 18:03:58 <jds2001> Kevin_Kofler: i dont think it's intended to 18:04:06 <jds2001> but that's outside of the scope here :) 18:04:25 <nirik> this sounds good. Is it already in? 18:04:25 <Kevin_Kofler> +1 to HarfBuzz - finally! Qt 4 has used this for ages. I hope this will improve consistency of font rendering. 18:04:27 <skvidal> it's unclear to me that harfbuzz is testable now? 18:05:03 <dgilmore> skvidal: indeed im leaning towards -1 based on the feature page it alls eems to be in an upstream git repo 18:05:06 <Kevin_Kofler> skvidal: Use any Qt 4 app and you're testing HarfBuzz. ;-) 18:05:12 <skvidal> Kevin_Kofler: in pango? 18:06:19 <nirik> I'd be ok with it if it's testable, but it's unclear if it is. Can we ask for clarification and punt to friday/ 18:06:25 <Kevin_Kofler> Let me check if Pango in devel is using HarfBuzz yet... 18:06:54 <Kevin_Kofler> Doesn't look like it. 18:06:58 <jds2001> :( 18:07:05 <Kevin_Kofler> It seems it's vanilla 1.24.5 at the moment. :-( 18:07:08 <skvidal> If it is not testable then -1 18:07:18 <jds2001> -1, not testable. 18:07:21 <sharkcz> -1 18:07:30 <nirik> ok, -1 then if it's not in. 18:07:34 <notting> yeah, -1 as it doesn't look testable yet 18:07:39 <Kevin_Kofler> IMHO it should go in. 18:07:51 <dgilmore> -1 18:07:54 <jds2001> #agreed Harfbuzz feature is declined, as it is not testable. 18:08:03 <Kevin_Kofler> We're having several problems on the KDE spin with GTK+ apps looking different from Qt/KDE ones. 18:08:10 <Kevin_Kofler> A HarfBuzz Pango is likely to fix that. 18:08:18 <Kevin_Kofler> So I think it should be able to go into F12 even late. 18:08:20 <jds2001> Kevin_Kofler: it may still yet land. 18:08:38 <skvidal> Kevin_Kofler: please remember - this is only declaring if these are features 18:08:41 <jds2001> but anyhow 18:09:08 <Kevin_Kofler> Land, but not be documented as such? This is really ridiculous and IMHO the worst failure of our feature process. 18:09:14 <jds2001> shall we move to virt tck? 18:09:20 <skvidal> jds2001: sure 18:09:30 <jds2001> #topic VirtTCK 18:09:31 <skvidal> jds2001: can you provide the link to it, again 18:09:34 <Kevin_Kofler> We should also allow late features when we allow freeze overrides. 18:09:40 <jds2001> sure 18:09:40 * nirik notes the mediarepo feature owner is in devel if we want to ask them to join and answer questions on that. 18:09:59 <jds2001> .fesco 223 18:10:11 <jds2001> nirik: that would be awesome, that way we dont defer it :) 18:10:14 <Kevin_Kofler> So Virt TCK was +4 -3 last week, with dgilmore and jwb absent. 18:10:26 <jwb> one sec 18:10:29 <jds2001> jwb is absent now as well 18:10:32 <jds2001> or not :) 18:10:39 <jwb> i had a conflict at 1 18:10:45 <jds2001> oh, np 18:10:52 <jwb> give me one sec to catch up 18:11:11 <dgilmore> +1 18:11:20 <jds2001> +1, as last week 18:11:45 <dgilmore> its testable and seems generally useful 18:12:04 <jwb> out of curiosity, what were the -1 vote based on? 18:12:16 <Kevin_Kofler> Not a feature, just an internal process improvement. 18:12:26 <notting> not a feature - having a test suite is not a feature. 18:12:44 <jds2001> and we believe it's a feature useful to enterprises and such. 18:12:47 <Kevin_Kofler> Yeah, myself, nirik and notting voted -1 on Friday. 18:12:49 <sharkcz> +1 as last week 18:13:11 <jds2001> we == everyone who didn't vote -1 :) 18:13:13 <jwb> jds2001, if you mean "as a selling point for enterprise distros", sure 18:13:32 <jwb> i'm going to have to go with a -1 as well. i was thinking the same already 18:13:54 <jwb> test suites are good, we'd like more of them, but they aren't Features 18:14:18 <skvidal> -1, not a feature - and difficult to explain to others. 18:14:37 <Kevin_Kofler> j-rod, skvidal, jds2001 and sharkcz voted +1 last time. Looks like skvidal is changing to -1? 18:14:47 <skvidal> yes 18:14:58 <skvidal> swayed to understand it is not a feature 18:15:41 <Kevin_Kofler> OK, so we now have -1 votes from me, jwb and skvidal. nirik, notting: ping? Are you confirming your -1 votes from last week? 18:15:50 <notting> yes. 18:16:24 <jds2001> #agreed VirtTCK does not meet the definition of a feature. 18:16:54 * jds2001 does not personally agree with that assessment, but that's why we have a voting system :) 18:16:56 <jwb> jds2001, we should note it was not unanimous 18:17:08 <jwb> nirik, does meetbot do that? 18:17:22 <onekopaka> jwb: yep. 18:17:32 <Kevin_Kofler> Uh, not really. 18:17:37 <Kevin_Kofler> Meetbot logs the whole discussion. 18:17:39 <onekopaka> #noted Decision on VirtTCK was not unanimous. 18:17:43 <jds2001> #note the previous vote was not unamious 18:17:49 <jwb> onekopaka, thanks! 18:17:51 <nirik> yeah, just via that. 18:17:57 <Kevin_Kofler> But it doesn't log scores until you note it explicitly. 18:18:02 <nirik> can we move on? 18:18:06 <jds2001> sure 18:18:14 <jds2001> is the media repo owner still around? 18:18:35 <nirik> let me check 18:18:46 <nirik> or skvidal can check. 18:19:34 <jds2001> :) 18:19:50 <nirik> in any case he has patches that work, but they use hal. 18:20:10 <notting> have the patches been okayed by their respective upstream? 18:20:14 <nirik> He needs to port them to using GIO. The packagekit maintainer is receptive to adding them, but they don't exist yet. 18:20:30 <nirik> (at least thats how I understand it) 18:20:50 <jds2001> hmmm 18:20:59 <skvidal> notting: the upstream has said no b/c of the hal use aiui 18:21:05 <Kevin_Kofler> Ugh, GIO? :-/ 18:21:14 <nirik> I don't know on yum. Perhaps we could find the yum maintainer and ask. ;) 18:21:20 <Kevin_Kofler> Isn't the core of PackageKit supposed to be independent of glib? 18:21:24 <skvidal> nirik: they are not patches to yum 18:21:37 <skvidal> nirik: none of this gets down to the yum layer - only yumex and PK 18:21:43 <nirik> well, the feature also lists yum as being a target I thought. 18:22:01 <jds2001> an optional one iirc 18:22:06 <Kevin_Kofler> Hmmm, upstream for PK is also our PK maintainer. 18:22:09 <nirik> Yum (if we want this feature in yum-cli) 18:22:17 <Kevin_Kofler> So if he doesn't want the patches, they're not likely to go in for F12. 18:22:19 <skvidal> nirik: yum-cli is not going to have mediahandling 18:22:41 <Kevin_Kofler> I don't see why using HAL is that big an issue. There's plenty of stuff still using it. 18:22:47 <nirik> well, in any case I don't know that it's testable now. (a out of tree hal patch is, but thats not going to be what goes in) 18:22:59 <jds2001> well surely everyone agrees that new stuff shouldntr 18:23:13 <nirik> Kevin_Kofler: PackageKit doesn't depend on hal anymore... they don't want to readd it just for this feature. 18:23:56 <nirik> oh well, I guess he's not around... punt to friday? 18:24:56 <skvidal> nirik: or just go with no 18:25:22 <nirik> that works for me too. 18:25:32 <notting> given that the patches aren't in (ergo, not testable) and upstream is not planning to accept the patches as-is... i'd vote -1. 18:26:06 <nirik> yeah, based on the current info I have, -1 here too. 18:26:06 <notting> Kevin_Kofler: current PK daemon already is at least linked against glib and gio 18:26:19 <nirik> keep trying and get it in next time. 18:26:20 <sharkcz> -1, it's not ready 18:26:20 <Kevin_Kofler> Well, then GIO looks like the way to go. 18:26:25 <Kevin_Kofler> But yeah, it's not there yet. 18:26:42 <dgilmore> -1 18:26:49 <jds2001> -1 18:26:51 <Kevin_Kofler> So I'll change my +1 to -1 too, the feature is not even written (in a way which will be accepted) yet! 18:27:28 <jds2001> #agreed media repo feature is declined for F12 18:27:31 <jds2001> we done? 18:27:45 <Kevin_Kofler> The PK maintainer is also PK upstream, if he doesn't like the patch, he sure won't commit it in Fedora unless we force him to (and I don't think we should). 18:27:57 <jds2001> anyhow, we 18:28:03 <jds2001> are done here :) 18:28:15 <jds2001> #endmeeting

3 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel July 2009