upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
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
1 year, 4 months
kernel/accounting question ...
by William W. Austin
(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 ..."
13 years, 5 months
acctcom for linux
by William W. Austin
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 ..."
13 years, 5 months
Packages looking for new owners
by Trond Danielsen
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
13 years, 6 months
Orphaning packages
by Conrad Meyer
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>
13 years, 7 months
Possible packages...
by Nathanael D. Noblet
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?
13 years, 8 months
xulrunner-1.9.1.1-1.fc11.x86_64 update pulls in i586 packages
by Braden McDaniel
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>
13 years, 9 months
FESCo meeting summary for 20090729
by Jon Stanley
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...
Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-29/fedora-meeting...
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
13 years, 9 months
