Make upstream release monitoring (the service formerly known as FEVer) opt-out?
by Till Maas
Hiyas,
currently upstream release monitoring[0] bug filing is opt-in, which
means that it will be only performed for packages that have been activly
added by probably a maintainer of the package. There is at least one
maintainer that does not like having these bugs filed for his packages,
so he can remove his packages from the list.
It might be easily possible in the future to monitor a bunch more
packages and create bugs in case there are newer versions available at
upstream.
Would it be ok, to do this and allow maintainers to add there package to
a black list, so that no bugs will be filed or should it continue to be
opt-in? Then the packags will still be checked, but only reported by
other, non intrusive ways, e.g. via a website.
Regards
Till
[0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring
14 years, 9 months
- 10
- 21
tcl / tk without threads??!!
by Paulo Cavalcanti
Can someone explain why tcl/tk is
compiled using:
%configure --disable-threads
This breaks some python programs, which use threads and Tk, with the
following error:
Unhandled exception in thread started by <function updateClock at
0x7fb431cc28c0>
Traceback (most recent call last):
File ".//08-clock-bezier.py", line 188, in updateClock
setClock (h,m,s)
File ".//08-clock-bezier.py", line 173, in setClock
clock.itemconfigure("hands", fill=colors[sector])
File "/usr/lib64/python2.5/lib-tk/Tkinter.py", line 2243, in itemconfigure
return self._configure(('itemconfigure', tagOrId), cnf, kw)
File "/usr/lib64/python2.5/lib-tk/Tkinter.py", line 1188, in _configure
self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError: out of stack space (infinite loop?)
Please, check this issue:
http://mail.python.org/pipermail/python-bugs-list/2008-September/060100.html
It happens on F10 and F11.
Thanks.
--
Paulo Roma Cavalcanti
LCG - UFRJ
14 years, 9 months
- 3
- 6
Fedora 12 Alpha Blocker Bug Meeting #4
by John Poelstra
Thanks to everyone who came and participated. Another successful
blocker review meeting was had today.
A reminder that at the Release Engineering meeting on Monday at 1800UTC
(2PM EDT, 11AM PDT) on #fedora-meeting, another review of the Fedora 12
Alpha blocker will be performed to see if we can still meet the current
schedule.
Thanks,
John
============================================
#fedora-bugzappers: F12 Alpha Blocker Review
============================================
Meeting started by jlaska at 15:00:07 UTC. The `full
logs`_ are available.
.. _`full logs`: fedora-bugzappers.2009-08-07-15.00.log.html
Meeting log
-----------
* **gathering** (jlaska-15:00:34_)
* *LINK*:
https://bugzilla.redhat.com/showdependencytree.cgi?id=507676&hide_resolved=1
(jlaska-15:09:04_)
* **bug#499854 - https://bugzilla.redhat.com/show_bug.cgi?id=499854**
(jlaska-15:09:22_)
* *AGREED*: Move 499854 to ASSIGNED, and reassess blocker potential
after jgranados has had a chance to review (jlaska-15:18:16_)
* **bug#512845 - https://bugzilla.redhat.com/show_bug.cgi?id=512845**
(jlaska-15:18:43_)
* *LINK*: http://koji.fedoraproject.org/koji/buildinfo?buildID=126008
(Alticon-Brian-15:25:29_)
* *ACTION*: follow-up with caillon/stransky/jhorak to disable the jit
for Alpha (jlaska-15:27:42_)
* *AGREED*: reach out to caillon/stransky/jhorak for input on
disabling jit in F-12-Alpha firefox ... remain as a blocker
(jlaska-15:29:16_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=513879**
(jlaska-15:29:44_)
* *IDEA*: f13 asks ... should firefox be added to critical path
(jlaska-15:40:29_)
* *AGREED*: 513879 in MODIFIED and awaiting verification once tagged
and composed for the Alpha (jlaska-15:45:38_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=515091**
(jlaska-15:45:48_)
* *LINK*:
https://fedoraproject.org/wiki/QA:Fedora_12_Alpha_Install_Test_Results
(jlaska-15:53:18_)
* *AGREED*: test fix for 515091 and revisit priority of this test if
issue remains unresolved (jlaska-16:04:56_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=515441**
(jlaska-16:05:59_)
* *AGREED*: move 515441 to F12Blocker and reassess should new
information come in (jlaska-16:09:24_)
* *ACTION*: jlaska to update description to match current status of
515441 (jlaska-16:09:38_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=515472**
(jlaska-16:10:38_)
* *AGREED*: 515472 - both reboot problems have fixes in and awaiting
verification on new anaconda. (jlaska-16:12:37_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=515555**
(jlaska-16:13:24_)
* *ACTION*: notting tracking down an owner to build a new yaboot for
515555 (jlaska-16:17:28_)
* *AGREED*: 515555 stays as a F-12-Alpha blocker. Posted patch
verified and awaiting package build+tag+compose (jlaska-16:17:56_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=515564**
(jlaska-16:18:13_)
* *AGREED*: 515564 remains as alpha-blocker. Fix in and awaiting new
anaconda for verification (jlaska-16:23:05_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=515905**
(jlaska-16:23:18_)
* *AGREED*: 507093 - stay on F12Alpha and discuss state of yum repo
edit dialogs with anaconda-devel (jlaska-16:31:16_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=516042**
(jlaska-16:31:46_)
* *AGREED*: 516042 - stay on F12Alpha and discuss state of yum repo
edit dialogs with anaconda-devel (jlaska-16:33:26_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=516053**
(jlaska-16:33:45_)
* *AGREED*: 516053 - involves manual edits of yum repo dialog, moved
to F12Beta ... however, fix available in next anaconda build
(jlaska-16:40:12_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=516063**
(jlaska-16:40:30_)
* *AGREED*: no action required - include in discussion w/
anaconda-devel on yum repo edit dialog status (jlaska-16:45:30_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=516144**
(jlaska-16:45:35_)
* *AGREED*: 516144 - consistent with f13 law ... blocks testing on
ppc64 platform. fixed in git already and awaiting build+tag
(jlaska-16:47:56_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=516168**
(jlaska-16:48:03_)
* *AGREED*: 516168 - introduced by recent udev changes, blocks all
installation. Fix in git and awaiting build+compose+verification
(jlaska-16:51:33_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=515410**
(jlaska-16:52:31_)
* *AGREED*: 515410 - results in no mouse cursor during installation.
Remains on F-12-Alpha, (jlaska-17:05:32_)
* **proposed blockers** (adamw-17:06:21_)
* *LINK*: https://bugzilla.redhat.com/show_bug.cgi?id=515129
(poelcat-17:06:26_)
* *LINK*: https://bugzilla.redhat.com/show_bug.cgi?id=505725
(poelcat-17:06:27_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=515129**
(adamw-17:09:44_)
* *AGREED*: 515129 is not a blocker. needinfo requested
(adamw-17:15:16_)
* **https://bugzilla.redhat.com/show_bug.cgi?id=505725**
(adamw-17:15:26_)
* *AGREED*: 505725 is not a blocker, no action required from us
(adamw-17:28:41_)
Meeting ended at 17:36:53 UTC.
Action Items
------------
* follow-up with caillon/stransky/jhorak to disable the jit for Alpha
* jlaska to update description to match current status of 515441
* notting tracking down an owner to build a new yaboot for 515555
Action Items, by person
-----------------------
* jlaska
* jlaska to update description to match current status of 515441
* notting
* notting tracking down an owner to build a new yaboot for 515555
* **UNASSIGNED**
* follow-up with caillon/stransky/jhorak to disable the jit for Alpha
People Present (lines said)
---------------------------
* jlaska (251)
* f13 (139)
* adamw (110)
* notting (41)
* maxamillion (39)
* buggbot (24)
* alindebe (19)
* poelcat (15)
* jgranados (8)
* Alticon-Brian (8)
* clumens (5)
* mclasen (3)
* iarlyy (2)
* daMaestro (1)
* Sparks_too (1)
* tk009 (1)
* sseiersen|Laptop (1)
Generated by `MeetBot`_
.. _`MeetBot`: http://wiki.debian.org/MeetBot
Minutes:
http://meetbot.fedoraproject.org/fedora-bugzappers/2009-08-07/fedora-bugz...
10:36:53 < zodbot> Minutes (text):
http://meetbot.fedoraproject.org/fedora-bugzappers/2009-08-07/fedora-bugz...
10:36:56 < zodbot> Log:
http://meetbot.fedoraproject.org/fedora-bugzappers/2009-08-07/fedora-bugz...
14 years, 9 months
- 1
- 0
rt2860 driver (fc11)
by Markus Kesaromous
I know this is a staging and thus experimental driver.
I only wanted to point out that if you compile the kernl
without SMP support, then this driver module will have these
undefined symbols:
spin_lock_bh
_per_cpu_offset
synchronize_irq
spin_unlock_irqrestore
del_timer_sync
spin_lock_irqsave
I did a cursory look at part of the code, and it is obvious
this code is not up to snuff in coding style, and in one file, missing
header include.
At the very least, the code needs to surround locking
and unlocking code with
#ifdef CONFIG_SMP
spin_lock... or spin_unlock ...
#endif
My $.02's worth
Cheers,
Markus K.
_________________________________________________________________
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_Ba...
14 years, 9 months
- 11
- 24
FESCo meeting summary for 20090807
by Jon Stanley
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2009-08-07/fedora-meeting...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2009-08-07/fedora-meeting...
Log:
http://meetbot.fedoraproject.org/fedora-meeting/2009-08-07/fedora-meeting...
---
17:00:19 <jds2001> #startmeeting FESCo meeting 2009-08-07
17:00:20 <jds2001> #chair dgilmore jwb notting nirik sharkcz jds2001
j-rod skvidal Kevin_Kofler
17:00:27 * nirik is here.
17:00:32 <jds2001> FergatROn: in #fedora-websites
17:00:40 <Kevin_Kofler> Present.
17:00:46 <FergatROn> jds2001: the meeting is on #fedora-websites channel?
17:00:47 <FergatROn> odd
17:00:55 * skvidal is here
17:01:00 <jds2001> FergatROn: yeah, the websites meeting conflicts with FESCo
17:01:06 <FergatROn> jds2001: thanks
17:02:18 * notting is here now
17:02:25 <jds2001> cool
17:02:35 <jds2001> shall we get started?
17:02:48 <jds2001> #topic MW Patch issue
17:02:54 <jds2001> .fesco 225
17:03:06 <jds2001> Kevin_Kofler: you have an update here?
17:03:19 <Kevin_Kofler> So some discussion got started after this got
escalated, I had hoped they'd find a resolution. Unfortunately, the
discussion has since dried out.
17:03:37 <jds2001> yeah , me too :(
17:03:56 * ricky would be happy to restart the discussion - I just
need to do some testing on some of the methods mentioned
17:04:51 <jds2001> that does no good if the maintainer doesnt apply
your patch :(
17:04:54 <nirik> shall we let ricky do that and revisit in a while? or ?
17:04:59 <jds2001> sure
17:05:26 <jds2001> #topic outdated wiki
17:05:30 <jds2001> .fesco 176
17:05:33 <Kevin_Kofler> nirik: Sure.
17:05:41 <jds2001> so our wiki pages are in various states of fail.
17:05:50 <j-rod> Running late, sorry
17:06:16 <jds2001> notting wanted to appoint someone to JFDI :)
17:06:23 <notting> jds2001: yeah, my goal was to bring this up so that
the 'Assigned to' part of this ticket is no longer blank
17:06:25 <jds2001> which seems reasonable
17:07:00 <jds2001> volunteers?
17:07:20 * jds2001 hears crickets
17:08:25 <nirik> Finding the time is the big thing. ;( Perhaps some
docs people would be willing to help out?
17:08:39 <jds2001> yeah, -ENOTIME here too :(
17:09:12 <jds2001> ianweller: you around?
17:09:26 <Kevin_Kofler> Before appointing something to do the work, we
should agree on what should be done.
17:09:26 <nirik> or call for helpers on the devel list?
17:09:34 * jds2001 defers to the wiki czar
17:09:36 <Kevin_Kofler> So the plan for the template page is to turn
it into a Trac template?
17:09:48 <Kevin_Kofler> That needs somebody with Trac admin privileges
to handle.
17:09:49 <jds2001> Kevin_Kofler: i think that makes sense, I can do that
17:09:53 <ianweller> jds2001: sorta!
17:09:58 <Kevin_Kofler> Then the wiki page can be removed.
17:10:13 <ianweller> uh oh "perhaps some docs people are willing to
help out / ianweller: you around?" bad combination for me. ;)
17:10:18 * nirik looks more closely at the ticket again.
17:10:30 <Kevin_Kofler> For the schedule page, I think we should be
linking to https://fedorahosted.org/fesco/report/9
17:10:42 <jds2001> ianweller: no, we're just saying that our pages are
in a state of fail
17:10:47 <nirik> so that gets rid of a few pages on the wiki side, but
we need to clean up the overall tree of fesco pages.
17:10:50 <ianweller> ok
17:11:11 <jds2001> we're looking for some assistance to get them out
of said state of fail :)
17:11:37 <ianweller> i'm usually around to answer questions in
#fedora-docs (or even #fedora-devel)
17:12:42 <jds2001> alright, I'll put out a call for a proposal on what
should be done
17:12:43 <nirik> so, looking at the
http://fedoraproject.org/wiki/PackageMaintainers page, I would say we
should look at: renaming category pages consistently, putting
"policies" in one area, and "suggestions" in another and
"guides/howtos" in another?
17:12:44 <skvidal> jds2001: we could just change them to say "ask
jds2001 on irc if you need to know something"
17:12:46 <Kevin_Kofler> Why the heck is the EPEL page embedded or
copypasted into the Development/Schedule page?
17:12:46 <Kevin_Kofler> It has nothing to do with scheduling.
17:13:02 <jds2001> Kevin_Kofler: i dunno :)
17:13:13 <Kevin_Kofler> I can clean up the page, there won't be much
left though. ;-)
17:13:24 <nirik> Kevin_Kofler: looks like a cut and paste error. ;(
17:13:28 <Kevin_Kofler> Mostly just one or more links to Trac.
17:14:25 <Kevin_Kofler> Hmmm, indeed, it should probably be embedding
EPEL/Schedule.
17:14:26 <jds2001> my trac plugin package review got approved, I'm
just waiting for CVS on it.
17:14:27 * dgilmore is kinda here
17:14:28 <Kevin_Kofler> Not the main EPEL page.
17:14:55 <nirik> Kevin_Kofler: not sure why it would have any epel
content there...
17:14:59 <jds2001> and then I can get it into infra, and enable it for
our instance.
17:15:05 * nirik will run the cvs queue after this meeting.
17:15:30 <Kevin_Kofler> OK, well, let's do some proposals for cleanup
and try to do fast votes?
17:15:56 <Kevin_Kofler> Proposal 1: delete EPEL section (embedding of
EPEL page) from Development/Schedule
17:16:09 <Kevin_Kofler> +1
17:16:11 * jds2001 is in favor of just delegating to someone and
letting them do what they see fit :)
17:16:13 <nirik> sounds fine. just do it.
17:16:28 <jds2001> it is after all a wiki :)
17:16:53 <Kevin_Kofler> Well, then I'll take care of the page if it's
fine with everyone.
17:17:01 <jds2001> sure thing
17:17:07 <nirik> fine with me. ;)
17:17:16 <notting> go for it
17:17:19 <jds2001> I'll go through and see what can be done to make it
more cohesive, too.
17:17:28 <jds2001> The whole structure, etc
17:17:38 <Kevin_Kofler> The EPEL content is a redirect from the
obsolete Extras/Schedule/EnterpriseExtras page.
17:17:49 <Kevin_Kofler> That's how it happened.
17:18:14 <nirik> I think naming the subpages in a good way, and making
subcategories for policy/suggestions/howtos would help a lot.
17:18:23 <Kevin_Kofler> There are a few obsolete and blank/nonexistent
Extras/Schedule/* pages it's trying to embed too.
17:18:40 <jds2001> #action Kevin_Kofler will clean up the schedule page
17:18:51 <jds2001> #action jds2001 will look at it as well
17:19:11 <jds2001> next!
17:19:22 <jds2001> #topic Fedora packages as canonical upstreams
17:19:28 <jds2001> .fesco 210
17:19:59 * jds2001 sees no additional information
17:20:02 <jds2001> defer again?
17:20:17 * abadger1999 notes that although I tried to clarify things
on the mailing list, I'm not for or against it.
17:20:19 <jds2001> irc there was a mailing list thread, though
17:20:21 <nirik> yeah, no more info from mether except the thread on devel list.
17:20:39 <nirik> if this is just to remove that exception from that
one guideline it should say so.
17:20:41 <abadger1999> jds2001: What do you need to know? Maybe I can
fill in blanks
17:20:57 <jds2001> i guess what's the problem space?
17:21:04 <jds2001> why doesnt this work now?
17:21:19 <abadger1999> AFAIK from talking to mether, removing the
exception from the guidelines is all that's wanted.
17:21:19 <dgilmore> i think tarballs are needed
17:21:20 <jds2001> what are we attempting to repair, and is it in need
of repair? :)
17:21:36 <nirik> abadger1999: is it just asking to remove that
guideline? or is it also asking to add stuff about requiring upstreams
to have a "proper hosting infrastructure"
17:21:51 * jds2001 thought the latter
17:22:00 <notting> so, the only possible consequence is we have source
tarballs for some packages that it is unclear of their origin (or they
resolve to some place not publically available)
17:22:01 <notting> ?
17:22:02 <nirik> abadger1999: I would be for it if he would redo this
to clarify that. The current proposal doesn't really say that.
17:22:23 <abadger1999> nirik: AFAIK, it does not require upstream to
have a proper hosting infra. However, if they do not have some sort
of public place to get the source (outside of our lookaside) it won't
pass review.
17:22:50 <abadger1999> source could equal tarball or version control,
etc... anything already allowed to non-Fedora/Red Hat projects
currently.
17:22:52 <nirik> abadger1999: thats currently the case for anything
thats not using that exception, right?
17:23:03 <abadger1999> Correct.
17:23:16 <notting> abadger1999: "i just wrote this, the tarball is now
sitting in my fedorapeople dir". is that acceptable for review?
17:23:19 <nirik> I would personally be fine with that.
17:23:33 <jds2001> what about pacakges where there is no source?
17:23:44 <nirik> notting: if thats the upstream location, i would say sure.
17:23:52 * jds2001 ran into another one last night, though not in the
context of fedora
17:23:57 <abadger1999> notting: Good question. Are you planning on
continuing to host the tarballs for subsequent versions there?
17:24:01 <dgilmore> notting tjhatss ok
17:24:03 <jds2001> namely oracle-lib-compat from spacewalk
17:24:16 <nirik> jds2001: no source? everything is in the spec?
17:24:25 <jds2001> nirik: indeed
17:24:25 <notting> abadger1999: well, we're speaking in hypotheticals,
here. 'maybe'?
17:24:39 <jds2001> it's a horrible hack, but will never be in Fedora :)
17:24:39 <abadger1999> notting: because, I think it satisfies the
criteria. But someone (like nirik's from source script) would be
legitimately calling you out if the future tarballs didn't exist at
some location later.
17:24:41 <nirik> jds2001: then it doesn't matter, because there is no
Source* field, right?
17:24:43 <notting> abadger1999: but i think we can claim that the only
case you'd hit this is self-written criteria
17:24:47 <notting> erm
17:24:48 <jds2001> nirik: correct
17:24:49 <notting> self-written software
17:25:27 <notting> so, slightly rephrasing it:
17:25:51 <nirik> we can't force upstream projects to always exist,
always have a reachable hosting site where we can get code, etc.
17:26:05 <dgilmore> jds2001: it will never be in fedora
17:26:10 <jds2001> dgilmore: riht
17:26:19 <jds2001> dgilmore: but who says other things like it may not?
17:26:47 <notting> Proposal: "We are upstream" section should be
removed from https://fedoraproject.org/wiki/Packaging:SourceURL.
source should still be downloadable from somewhere.
17:26:56 <abadger1999> nirik: <nod> But for an upstream project that
no longer has an upstream tarball, we'd say, this upstream seems to be
dead, you need to either retire the package or get the latest ersion
of the source and start hosting it somewhere.
17:27:02 <nirik> notting: +1 here. I assume thats what mether wanted...
17:27:12 <dgilmore> 389-ds has no source
17:27:18 <nirik> abadger1999: yep. I think thats fine... it's the best
we can do.
17:27:19 <abadger1999> notting: Good rewrite.
17:27:53 <jds2001> dgilmore: that's the metapackage for 389?
17:28:12 <dgilmore> yep
17:28:13 * nirik waits for more votes so we can move on. ;)
17:28:33 <Kevin_Kofler> I still don't see why it's so important to
have a tarball outside of the SRPM / the lookaside cache.
17:28:47 <Kevin_Kofler> I think it doesn't make sense to require it.
17:28:51 <Kevin_Kofler> So -1 to notting's proposal.
17:28:54 <nirik> Kevin_Kofler: I don't care about tarball... but I
think the source should be available somehow.
17:29:02 <nirik> Kevin_Kofler: he didn't say tarball.
17:29:06 <Kevin_Kofler> The SRPM is "somehow".
17:29:06 * jds2001 is wondering about things that have no source, such as 389-ds
17:29:13 <Kevin_Kofler> As is the lookaside cache.
17:29:15 <nirik> jds2001: how does it work then?
17:29:23 <Kevin_Kofler> jds2001: Or kde-filesystem.
17:29:26 <nirik> Kevin_Kofler: example?
17:29:31 <abadger1999> I think i makes sense to have one outside of
the SRPM. outside of lookaside I'm not 100% on but it's cleaner to
have less exceptions.
17:29:38 <Kevin_Kofler> Well, kde-filesystem actually has a source for
the RPM macros.
17:29:50 <jds2001> nirik: it requires other things
17:29:50 <nirik> Kevin_Kofler: where do you store that?
17:29:51 <abadger1999> No source wouldn't be affected one way or
another by this exception.
17:29:55 <jds2001> nirik: it's a metapackage
17:29:59 <Kevin_Kofler> But there are pure *-filesystem packages with
no source file at all, just mkdir statements in the specfiles.
17:30:10 <nirik> jds2001: then it doesn't matter here. This only
affects things with Source: urls
17:30:14 <abadger1999> So keeping or removing it won't affect 389-ds,
kde-filesystem, etc.
17:30:30 <nirik> Kevin_Kofler: thats fine, they have no Source field.
They don't matter here.
17:30:37 <Kevin_Kofler> The source for the macros in kde-filesystem?
It's a trivial text file and it's stored within CVS (not even
lookaside cache).
17:30:38 * abadger1999 checks what's in kde-filesystem
17:31:06 <nirik> Kevin_Kofler: cool. then that could be the source for
it? I don't think thats a problem.
17:31:20 <Kevin_Kofler> Source1: teamnames <-- That's for i18n/l10n directories.
17:31:20 <Kevin_Kofler> Source2: macros.kde4 <-- The RPM macros.
17:31:26 <Kevin_Kofler> Both are text files checked into CVS.
17:31:42 <notting> text source: directly in SCM is fine with me. it's
not like we have separate hosting for .desktop files
17:31:44 <Kevin_Kofler> teamnames is 1516 bytes, macros.kde4 887 bytes.
17:31:51 <abadger1999> Yeah, that looks fine.
17:33:04 <abadger1999> If someones says its a problem FPC would
probably be better off making a better definition of what "source"
means than to use the exception limited to Fedora/Red Hat projects.
17:33:16 <nirik> yeah, agreed.
17:33:44 <notting> but i would still vote +1 to the propsal, on a "fix
this part, we can clarify more later if need be" basis
17:34:15 * jds2001 votes +1 to this proposal
17:34:19 <j-rod> +1
17:34:19 <nirik> yes, still +1 from me. I don't think we should have
the exception any more
17:34:57 <skvidal> +1 to notting's suggestion
17:35:01 <Kevin_Kofler> I'm still -1, I don't see the benefits of
removing the exception.
17:35:34 <jds2001> #agreed The Fedora packages as canonical upstream
excepton is removed.
17:35:53 <jds2001> #topic feature submisson deadlin
17:35:53 * nirik notes there is nothing in the packaging guidelines
that says source must be available.
17:35:58 <jds2001> .fesco 234
17:36:25 <jds2001> nirik: there is something that says no pre-built binaries
17:36:38 <jds2001> so i would assume that leads to source being available :)
17:37:13 <nirik> jds2001: sure, but it doesn't say source MUST be
provided at an upstream site. The SourceURL guideline is how to point
to it, but it doesn't say it has to exist...
17:38:07 <nirik> anyhow, sorry, move on.
17:38:21 * dgilmore is +1 i do think they should be a month after
17:38:43 <jds2001> a whole month?
17:38:46 <abadger1999> nirik: hmm... FPC can make that more explicit
if you want.
17:39:25 <dgilmore> but we could accept nearly complete ones for 2 weeks after
17:39:56 <nirik> abadger1999: yeah, might be something to consider.
The sourceurl page doesn't explicitly say that source MUST be
available upstream somehow, just how to address various ways upstream
might point to it.
17:40:01 <jds2001> and 100% complete for the remaining two weeks?
17:40:47 <jds2001> i.e. i forgot to write the feature page
17:40:49 <nirik> so what are we trying to solve here? the rush of
features at the deadline where they have not landed yet?
17:41:02 <jds2001> nirik: yeah, i think so
17:41:07 <dgilmore> jds2001: no
17:41:08 <notting> well, the rush of features at the deadline
17:41:12 <dgilmore> defer
17:41:28 <jds2001> defer? why?
17:41:31 <nirik> I think this could lead to more 'the feature is done
for the release, but I didn't know it would be in time/didn't make the
deadline' so we don't advertize it as a feature even though it's done.
17:42:09 <dgilmore> they have alot of time to get a page together and in
17:42:38 <Kevin_Kofler> nirik: Right.
17:43:11 <Kevin_Kofler> It will also lead to developers promising
stuff "just in case I can complete it" and us having to vote for a lot
more features, just to drop them 2-4 weeks later as not even started.
17:43:15 <nirik> I guess I would be ok with 2 weeks as long as we
granted exceptions in cases where they make sense.
17:43:44 <Kevin_Kofler> So -1 to this proposal, soft freezes just don't work.
17:44:48 <dgilmore> i never said soft
17:45:04 <dgilmore> 2 weeks hard
17:45:23 <dgilmore> 4 weeks if your not nearly done
17:45:43 <Kevin_Kofler> Soft freeze = you can work on features, but
only if you submitted them first.
17:45:46 <jds2001> but we would need to make exceptions to that rules too?
17:46:20 <Kevin_Kofler> And that's basically what your proposal is,
except that you can still work on features, but not advertise them as
such (which is about the worst part of our feature process, this
proposal doesn't help this issue).
17:46:52 <drago01> which can't be enforced anyway
17:46:53 <Kevin_Kofler> IMHO we should be able to advertise features
at any time, even in updates.
17:47:15 <drago01> updates?
17:47:15 <Kevin_Kofler> drago01: Not being able to work on features
can't be enforced, so that's how the problem happens.
17:47:28 <Kevin_Kofler> The only solution is to be more flexible for
advertising features as well.
17:47:38 <Kevin_Kofler> drago01: Often interesting new features get
backported to updates.
17:47:56 <Kevin_Kofler> Then they get advertised as "Fedora n
features", but they have been in Fedora n-1 and possibly even n-2
months earlier.
17:47:59 <Kevin_Kofler> This makes no sense.
17:48:15 <Kevin_Kofler> We need a way to advertise features as being in updates.
17:48:16 <nirik> Kevin_Kofler: but our feature process is tied to
releases... you want to announce some new F11 feature now?
17:48:27 <drago01> yeah but its not worth to advertise them months
after the release
17:48:34 <drago01> where nobody really cares anymore
17:48:40 <Kevin_Kofler> nirik: More like ~2 weeks from now when KDE
4.3 hits. :-)
17:48:50 <Kevin_Kofler> But it's not the only such feature.
17:49:01 <Kevin_Kofler> Graphics driver hardware support improvements
have also occasionally been backported.
17:49:12 <Kevin_Kofler> E.g. 3D for r5xx cards, IIRC in F9 updates.
17:49:14 <nirik> sure, but thats not a feature by our current process.
17:49:30 <jds2001> a lot of the reasoning for the feature process is
in order to prepare the press for what's coming in that release.
17:49:34 <nirik> features == things in the current release that are
there at release time.
17:50:49 <nirik> poelcat: you around? want to weigh in here as you
commented in the ticket.
17:51:53 <nirik> Kevin_Kofler: I think it might be nice to have some
standard way of noting big updates... ie, fedora-announce, some kind
of "press release", etc. But I think thats outside the scope of our
feature process.
17:52:06 * poelcat reads backscroll
17:52:15 <jds2001> well i know that kde4.3 is coming to F10/11
17:52:26 <jds2001> they've done a decent job of advertising that
17:52:37 <nirik> yeah, and it would be good to shout that out in some
standard/official way.
17:52:38 <jds2001> though i think the only way that i know is rex's
mail to f-d-a
17:53:09 <poelcat> my question is why this was such a "crisis" for
FESCo for F12? :)
17:53:13 <Kevin_Kofler> FYI, it's too early to announce it to end
users now, it should wait until the official update.
17:53:20 <poelcat> all the releases have been this way and things have
turned out fine
17:53:41 <nirik> poelcat: yeah. I think we got several more 'please
give us more time, it's about to be done' than the last few cycles...
17:53:46 <nirik> but there are always some of those.
17:53:47 <Kevin_Kofler> (i.e. stable, not just testing, where it's
queued for now)
17:54:23 * poelcat thinks the issue of "features" in "updates" is a
separate issue clouding this discussion
17:54:36 <Kevin_Kofler> As for the "please give us more time", I think
this has everything to do with the removal of the old Alpha release
and the rename of Beta to Alpha.
17:54:49 <Kevin_Kofler> It may be a problem of habit, i.e. that we
aren't used to this.
17:54:59 <nirik> poelcat: totally agreed there.
17:55:10 <Kevin_Kofler> Or it may be that the old Alpha milestone,
while mostly useless, served as a warning to get things done soon.
17:55:16 <poelcat> and a bigger discussion about increased process
complexity, etc.
17:55:56 <poelcat> so if you're asking me if I think a feature filing
deadline two weeks before FF is okay... I don't see any serious
downsides
17:56:41 <poelcat> just getting the word out and my email nags that
everyone seems to live to see ;-)
17:57:00 <poelcat> that is all from me
17:57:44 <jds2001> poelcat: i think the propsal was a month
17:58:00 <poelcat> jds2001: i thought someone counter-proposed 2 weeks
17:58:08 <jwb> notting did
17:58:12 <jwb> and i agreed with notting
17:58:15 <jds2001> poelcat: and we'll accept 90%+ (or whatever) unitl 2 weeks
17:58:38 * jwb is only like 10% here. apologies
17:58:48 <jds2001> jwb: np
17:59:05 <j-rod> I like the 2 week idea myself. 4 seems a bit much.
17:59:23 <poelcat> i think managing to exact percentages is going to
be more problems than it is worth... i'd recommend starting with two
weeks... all filed and see what happens
17:59:38 <jds2001> sounds good
17:59:56 * j-rod only here like maybe 11%...
17:59:59 <poelcat> if we want to rework the process and details of it
we should probably draw up a proposal and have a meeting about it vs.
trying engineer it all here now
18:00:07 <jds2001> let's change the proposal to a 2 week
deadline....all in favor?
18:00:19 <poelcat> where "process and details" == percentages, etc.
18:00:35 * Kevin_Kofler is still against the proposal, seeing more
drawbacks than benefits.
18:00:36 <jds2001> and how does one define a percentage?
18:01:16 <notting> jds2001: "a ratio between 0 and 1, multiplied by 100"
18:01:18 <Kevin_Kofler> (drawbacks as already discussed: "just in
case" filing of bogus/unimplementable features, features missing the
filing deadline but going in)
18:01:25 <jds2001> notting: :D
18:02:02 <Kevin_Kofler> In the case of features, it's more like "a
random number between 0 and 100".
18:02:10 <Kevin_Kofler> It isn't even always monotonically increasing over time.
18:02:20 <dgilmore> sorry network dropped out
18:03:34 * poelcat disappears
18:04:13 <jds2001> anyhow
18:04:17 <dgilmore> i think that it needs to be no less than 2 weeks
18:04:38 * nirik would be ok trying 2 weeks for the next cycle and
adjusting. I don't think it's going to change much though.
18:05:17 <dgilmore> im ok with that
18:05:21 <jds2001> +1 to two weeks
18:06:08 <Kevin_Kofler> My counterproposal: move the feature
submission deadline to at least 2 weeks AFTER the feature freeze.
Rationale: the features we document should reflect the features which
actually got implemented. The best moment to know that is after the
freeze.
18:07:13 <jds2001> -1, that's just silly
18:07:25 <nirik> I guess that depends on if we expect maintainers to
write up their proposal after they have done their implementation or
before...
18:07:28 <dgilmore> Kevin_Kofler: -1 seriously
18:07:39 <dgilmore> nirik: before
18:07:39 <nirik> I think before makes a lot more sense.
18:07:48 <j-rod> +1 for 2 weeks before
18:08:02 <skvidal> +1 for 2 weeks before, as well
18:08:13 <dgilmore> nirik: and before people can help complete them
18:08:20 <skvidal> -1 for writing it up after
18:08:40 <dgilmore> +1 for 2 weeks before
18:08:46 <nirik> it's a lot more open and community orented. ;)
18:08:57 * notting is +1 to two weeks before, -1 to two weeks later
18:09:23 <jds2001> #agreed feature submission deadline will be moved
to two weeks prior to feature freeze for F13
18:09:42 <jds2001> #topic upstrem release monitoring
18:09:55 <jds2001> .fesco 239
18:10:09 <jds2001> im not sure technically how this could conceivably function
18:10:30 <skvidal> I think it'll just create bugspam
18:10:34 <jds2001> the current manual system i can easily see how it functions
18:11:00 <notting> i believe tyll is on another channel, if he wants to join
18:11:05 <dgilmore> -1 i think this will just create noise
18:11:06 <jds2001> im all for trying it and putting it up on a webpage
or somesuch
18:11:14 <nirik> I think this could be usefull, but not in bugzilla...
18:11:21 <nirik> webpage + emails perhaps.
18:11:42 <Kevin_Kofler> I think the idea is that somebody will enter
the URLs for all packages whose maintainer(s) do(es)n't opt out by
hand.
18:11:45 <drago01_> well there are reasons why someone does _not_ want
to update to lastest upstream
18:11:48 <Kevin_Kofler> I don't see how it would work otherwise.
18:12:14 <Kevin_Kofler> I'm a bit worried about bad regexes getting
entered, leading to false positives (e.g. unstable/development
releases).
18:12:26 <j-rod> I'm going to go with "how 'bout no?" on this one.
18:12:49 <Kevin_Kofler> But in principle, I think monitoring by
default is a good idea if done properly.
18:12:50 <drago01_> getting spamed "update to foo" would be just annoying
18:13:16 <Kevin_Kofler> drago01_: I assume the system is smart enough
not to annoy you again with the same version if you close it once as
NOTABUG.
18:13:18 <j-rod> as a packager, I'm on the upstream mailing lists for
all the packages I maintain
18:13:22 <Kevin_Kofler> If it's not, it's really broken.
18:13:22 <j-rod> that's enough, thank you
18:13:54 <nirik> I think it's usefull in some cases, but it needs to
be hashed out more... and perhaps opt-in would make more sense.
18:13:59 <j-rod> (though not all projects have one)
18:14:12 <j-rod> opt-in is more reasonable than opt-out
18:14:18 <Kevin_Kofler> nirik: opt-in is what we currently have.
18:14:27 <Kevin_Kofler>
https://fedoraproject.org/wiki/Upstream_Release_Monitoring
18:14:27 <nirik> yeah
18:14:33 <jds2001> right, and regexes are manually entered
18:14:35 <jds2001> which is fine
18:14:46 <Kevin_Kofler> AIUI, the proposal is to have someone enter
regexes for the packages which don't have any.
18:14:51 <jds2001> they have the manpower to expand that to all packages?
18:16:02 <nirik> I think they don't realize what a job that will be if
they think they do. ;)
18:17:00 * jds2001 counts only 621 packages currently monitored
18:17:05 <jds2001> less than 10% coverage
18:17:55 <jds2001> anyhow, -1 to opt-out, +1 to opt-in
18:18:17 <notting> similar here. -1 to opt-out, +1 to opt-in
18:19:15 <nirik> yeah, ditto. Would be nice to use a website/email
process instead of bugzilla as well.
18:19:17 <j-rod> -1 opt-out, +1 opt-in
18:19:34 <Kevin_Kofler> +1 to opt-out, 0 to opt-in (also because I
don't see why that'd need our approval at all)
18:20:16 * nirik gets confused... checks to see if he voted as he intended.
18:20:32 <jds2001> im interested to know why you are in favor of an
opt-out system?
18:20:42 <dgilmore> -1 to opt out
18:20:58 <Kevin_Kofler> jds2001: Because that way lazy packagers would
get told to upgrade their package by default.
18:21:12 <Kevin_Kofler> Whereas those who have good reasons not to can
opt out and/or close the bugs as NOTABUG.
18:21:24 <nirik> shouldn't they anyhow when a user wants a newer
version for a specific reason?
18:21:24 <jds2001> Kevin_Kofler: said lazy packager would just opt out
18:21:46 <Kevin_Kofler> I'm thinking of the packager(s) too lazy to
opt in or out.
18:21:57 <jwb> i wasn't aware laziness was a trait we wanted to
promote in Fedora
18:21:58 <nirik> they would likely just pile up 'please update' bugs.
18:22:15 <Kevin_Kofler> I'm thinking there must be significant overlap
with the packagers who are too lazy to upgrade their packages.
18:22:43 <skvidal> -1 to opt out
18:22:52 <jds2001> if there's something new that folks want, I'll
upgrade my packages.
18:22:57 <jwb> anyway, i already expressed much of my opinion in the
ticket. i like the service, but i don't want it to be opt-out
18:23:03 <jwb> so -1 to opt-out
18:23:04 <jds2001> but upgrading just to upgrade is silly.
18:23:14 <Kevin_Kofler> nirik: We could have the system auto-start the
NRM/AWOL/MIA process.
18:23:34 <nirik> Kevin_Kofler: I think that would be hard to automate.
18:23:35 * jds2001 thinks that's an even worse idea.
18:23:44 <Kevin_Kofler> We'd catch lazy maintainers automatically that way.
18:24:14 * nirik thinks we are drifting off topic.
18:24:45 <jds2001> yeah, we have a boatload of features to consider.
18:25:38 <jds2001> #agreed Opt-out new package notification is not
allowed, opt-in is fine
18:26:05 <jds2001> #topic Drop non-testable features
18:26:39 <jds2001> so I haven't had a chance to follow the thread-o-doom
18:26:45 <jds2001> ,fesco 240
18:26:51 <jds2001> .fesco 240
18:26:56 <nirik> lets just go thru them case by case?
18:27:04 <jds2001> yeah
18:27:23 <jds2001> DisplayPort?
18:28:13 <Kevin_Kofler> Was updated this week, should be testable at
least with intel according to the status, -1 to dropping.
18:28:23 <jds2001> btw, since i havent had a chance to read the thread
in it's entirety, I'm not 100% sure I'm qualified to vote on these
since I've not seen potential feedback from owners.
18:28:27 * notting brings up the portion of the thread that doesn't
involve arguing over someone's review skill
18:28:57 <Kevin_Kofler> Well, just follow the link and throw a quick
glance of the linked feature pages, you'll get an opinion fairly
quickly.
18:29:25 <Kevin_Kofler> For DisplayPort, IIRC ajax said it's basically
done, though some bugs are left.
18:29:28 <nirik> yeah, -1 to dropping at this point...
18:29:44 <jds2001> ok, -1 to dropping
18:29:53 <j-rod> -1
18:29:57 <Kevin_Kofler> If only Intel gets done, we should rescope the
feature as Intel-only.
18:30:00 <notting> -1 to dropping for now. although if it's not going
to get much better, it probably needs reworked
18:30:19 <skvidal> that looks like 5
18:30:23 <skvidal> -1's that is
18:30:32 <nirik> next
18:30:33 <jds2001> #agreed DisplayPort feature is not dropped
18:30:36 <jds2001> FedoraStudio?
18:30:52 <jds2001> -1 to dropping, looks like it got updated today
18:30:59 <jds2001> and is mostly there
18:31:29 <nirik> yeah, -1 to drop here as well.
18:31:34 <notting> -1
18:31:37 <j-rod> -1
18:31:56 <Kevin_Kofler> Same here, -1 to dropping.
18:32:02 <skvidal> -1
18:32:08 <jds2001> #agreed FedoraStuido feature is not dropped
18:32:17 <jds2001> GFS2 clustered samba?
18:32:37 <jds2001> looks like some general GFS stability issues, looks
like it's in testing and bugfixing
18:32:47 <Kevin_Kofler> Updates yesterday, 90% complete, -1 to dropping.
18:32:55 <jds2001> -1 to dropping
18:33:05 <skvidal> -1
18:33:08 <notting> -1
18:33:12 <nirik> -1 (so negative we are today)
18:33:23 <jds2001> #agreed GFS2 Clustered Samba feature is not dropped
18:33:30 <jds2001> #agreed GFS2 Clustered Samba feature is not dropped
18:33:33 <jds2001> oops
18:33:36 <jds2001> Gnome 2.28?
18:33:41 <j-rod> -1
18:33:44 <notting> -1, because, well....
18:33:53 <jds2001> -1....
18:33:56 <notting> what's there is certainly testable.
18:34:15 <Kevin_Kofler> -1 to dropping, it's clearly being implemented
for F12 and a prerelease is already in.
18:34:23 <nirik> yeah, agreed.
18:34:28 <jds2001> #agreed Gnome 2.28 feature is not dropped
18:34:42 <jds2001> LowerProcessCapabilities?
18:35:06 <Kevin_Kofler> Hmmm, is the owner around?
18:35:15 <nirik> I don't see this as having landed/testable.
18:35:17 <jds2001> this one doesnt look to have been updated and is
rather worrisome at 20%
18:35:22 <Kevin_Kofler> This hasn't been updated for almost a month
and it says 20%.
18:35:32 <notting> as it stands, i'm +1 to dropping - it's not been
updated, and it does not appear to have landed in any way
18:35:40 <skvidal> +1
18:35:42 <jds2001> +1
18:35:47 <nirik> yep. +1 to drop and try again for next cycle.
18:36:16 <Kevin_Kofler> libcap-ng is in Rawhide.
18:36:20 <notting> (and it's the sort of thing that looks complex to
land totally)
18:36:22 <Kevin_Kofler> Package last updated 12 days ago.
18:36:36 <Kevin_Kofler> Whether anything actually uses it, I have no idea.
18:36:45 <j-rod> +1 to defer it
18:36:47 <jds2001> #agreed Lower Process Capabilties feature is dropped for F12
18:36:57 <jds2001> FedoraMoblin?
18:37:23 <skvidal> looks like it has the headway necessary -1 to dropping it
18:37:36 <Kevin_Kofler> sgrubb: So here you are. Any updates for
LowerProcessCapabilities?
18:37:53 <sgrubb> been working on dhcp requirements
18:37:54 <j-rod> I've noticed a number of new moblin packages landing
18:37:59 <jds2001> how are those two outstanding package reviews looking?
18:38:05 <nirik> new packages are landing, but it's not been added as a spin...
18:38:15 <sgrubb> chatted with the maintainer on that to understand
how to tackle that onbe
18:38:18 <Kevin_Kofler> Hmmm, we're discussion 2 features at once now.
18:38:30 <Kevin_Kofler> I pinged sgrubb so he could give an update on
LowerProcessCapabilities.
18:38:40 <sgrubb> got patch in for irqbalance and I think one other
18:38:50 * nirik nods. Lets go back to sgrubb's feature.
18:39:02 <sgrubb> My priority for the last 2 weeks had to be getting
audit-2.0 package ready
18:39:06 <Kevin_Kofler> Can you please update the feature page at
https://fedoraproject.org/wiki/Features/LowerProcessCapabilities ?
18:39:15 <Kevin_Kofler> Right now this is at 20% and not updated for
almost a month.
18:39:17 <sgrubb> its now blocked on package review for sc-audit
18:39:32 <jds2001> is audit-2.0 somehow related to this?
18:39:38 <jds2001> or is that something else?
18:39:52 <sgrubb> it takes my time so that I cannot work on
LowerProcessCapabilities
18:40:32 <jds2001> ok, fair enough
18:41:04 <jds2001> so are you OK if we defer this to F13 since you
didn't have time?
18:41:38 <sgrubb> no, I'm not. :)
18:41:55 <sgrubb> I am about done audit 2.0
18:42:27 * skvidal reiterates his -1 - this is not done and it is too late now
18:42:43 <Kevin_Kofler> You mean your +1 to dropping the feature?
18:43:05 <skvidal> yes, I did
18:43:32 * skvidal got the -1/+1 backward again
18:43:34 <skvidal> +1 for dropping
18:43:56 <Kevin_Kofler> I'm -1 to dropping it now, it looks like some
work got done already which is worth mentioning on its own, and more
is to come.
18:44:33 <nirik> but should we be making these kind of changes after freeze?
18:44:35 <Kevin_Kofler> I think we should give sgrubb a chance to
update the page and continue his work and revisit the feature later.
18:44:58 <sgrubb> alpha freeze?
18:45:03 <jds2001> we're now into "fix bugs stage"
18:45:11 <jds2001> sgrubb: alpha is the new beta
18:45:27 <jds2001> sgrubb: there's been confusion about that, and that's fair.
18:45:58 <nirik> I think it would be better to get everything ready
for this and land it early in the next cycle...
18:46:12 <jds2001> we dropped the alpha milestone we've had in
previous releases, and are now calling what used to be beta alpha
18:46:23 <notting> but the feature freeze is still at the same
relative point of the release
18:46:29 <Kevin_Kofler> jds2001: And I think that was a mistake.
18:46:44 <Kevin_Kofler> I think pretty much all our issues with stuff
not being ready are due to that.
18:46:56 <sgrubb> so from Fesco approval to freeze is 2-3 weeks...is that fair?
18:47:48 <jds2001> sgrubb: there's a separate proposal that was
approved earlier in the meeting to move feature submission to two
weeks prior to feature freeze
18:48:04 <jds2001> as of now, you could propose a feature on the day
of feature freeze.
18:48:36 <jds2001> and have it accepted
18:49:04 <jds2001> so hopefully that addresses that concern. Late for
now, I know.
18:49:30 <sgrubb> I created the Feature Page June 23 and it was not
approved until July26
18:49:44 <sgrubb> I lost a lot of time waiting to get the go ahead on this
18:49:54 <notting> it was not submitted to fesco until july 23
18:50:10 <notting> (we can't approve what we don't see)
18:50:20 <nirik> sgrubb: whats left to land before this would be testable?
18:50:56 <sgrubb> well, its kind of testable right now, its just not finished
18:51:03 <sgrubb> run netcap
18:51:04 <nirik> permissions changes in the base packages?
18:51:37 <sgrubb> I spoke with shadow-utils maintainer he told me to
see setup package maintainer
18:52:06 <sgrubb> that was my next step for getting perms a little tighter
18:52:29 <sgrubb> but based on conversation on the mail list, looks
like I can't do full permission change I originallyy proposed
18:52:38 <sgrubb> so I am scaling that bit back
18:53:11 <sgrubb> do shadow and gshaow is simple to fix
18:53:43 <sgrubb> taking root's write away from /bin /sbin /lib is also doable
18:54:15 <sgrubb> but the other dirs I don't this I can touch without
some thinking about it. So I don't want to do those at this point
18:54:39 <skvidal> sgrubb: taking root's write away from /bin and /sbin?
18:54:49 <sgrubb> yeah, 0555 perms
18:54:50 <skvidal> sgrubb: and what does that do for rpm?
18:55:05 <sgrubb> nothing, the admin has DAC_OVERRIDE
18:55:16 <Kevin_Kofler> Read the feature page, root is allowed to
write into stuff with no write permissions (even now).
18:55:32 <Kevin_Kofler> What's going to change is that daemons will
run as root but with that capability explicitly dropped.
18:55:36 <nirik> so how soon would this realistically land? the next few days?
18:55:44 <notting> Kevin_Kofler: only patched daemons, correct?
18:55:51 <Kevin_Kofler> Correct.
18:55:54 <sgrubb> yes
18:56:01 <Kevin_Kofler> They need to explicitly drop the capability.
18:56:22 <sgrubb> also...the current daemons that do drop capabilities
all have a security hole in them
18:56:35 <sgrubb> dbud dnsmasq for example
18:56:39 <sgrubb> dbus that is
18:56:51 * nirik still wonders if it wouldn't be better to just work
on this now and land it first thing after the next cycle branch...
18:57:24 <sgrubb> not all of this has to land now, it can be done in pieces
18:57:25 <nirik> so that way more could be done, and it would get
testing and not disrupt this shorter release cycle.
18:58:16 <nirik> sgrubb: could you then update the feature page with
what could realistically be done now? and move the rest to another
page for next cycle?
18:58:32 <sgrubb> sure, no problem with that
18:58:52 <notting> esp. given that it looks like only libcap-ng is
going to make the alpha, no users of it
18:58:54 <nirik> I'd be ok with that... but thats just me. ;) I guess
we need to vote?
18:59:27 <jds2001> +1 to new scope
19:00:05 <Kevin_Kofler> +1 to new scope as well
19:00:59 <jds2001> is anyone else still with us? :)
19:01:11 * skvidal is and is mulling things
19:01:26 <skvidal> fine +1 to new scope
19:02:07 <notting> +1 to reduced scope (still obviously needs to land
before beta)
19:02:38 <nirik> thanks for dropping and providing us info sgrubb. :)
19:02:40 <jds2001> #agreed LowerProcessCapabilities feature with
reduced scope is not dropped.
19:03:07 * jds2001 notes we're out of tmie
19:03:21 <jds2001> i'd like to get through the rest of these though
19:03:30 <jds2001> everyone cool with that?
19:03:40 <Kevin_Kofler> Yeah, let's continue.
19:04:08 <jds2001> alright, 6 more
19:04:10 * nirik nods.
19:04:19 <jds2001> FedoraMoblin
19:04:36 <nirik> great work being done there, but it needs
updating/reduced scope too, or defering until next cycle.
19:04:52 <nirik> the spin has not been submitted to the spins sig, so
no way that will make it this cycle.
19:05:12 <jds2001> ok, so let's drop this for this cycle
19:05:20 <Kevin_Kofler> Uhm, yeah, we approved it contingent on that,
so technically the approval is already no longer valid.
19:05:26 <jds2001> +1 to dropping
19:05:36 <Kevin_Kofler> The packages are almost all in (only 2
missing), but the spin is not. :-/
19:05:38 * nirik nods. drop to next cycle.
19:05:41 <Kevin_Kofler> Why haven't they submitted the spin?
19:05:46 <j-rod> +1, per what Kevin_Kofler said
19:05:47 <nirik> don't know.
19:06:09 <notting> +1 to dropping if the spin isn't there yet. plus,
their blocker bug shows 9 open reviews
19:06:39 <jds2001> #agreed Fedora Moblin is deferred to F13.
19:06:46 <jds2001> NetBeans 6.7?
19:07:37 <jds2001> looks to have have been updated
19:08:01 <Kevin_Kofler> Yeah, 70% complete, not testable yet as deps
are still missing. :-(
19:08:06 <notting> the page, yes. the packages, no
19:08:12 <Kevin_Kofler> So where do we go from there?
19:08:14 <jds2001> there's a review there that still needs a reviewer
19:08:16 <nirik> yeah, still lacking some packages that haven't been reviewed.
19:08:24 <jds2001> +1 to dropping
19:09:08 <tibbs> The queue was spammed quite a bit with moblin-related packages.
19:09:13 <j-rod> +1, spill the beans next release
19:09:14 <skvidal> +1 to dropping
19:09:18 <skvidal> j-rod: booo
19:09:22 <j-rod> :D
19:09:41 <tibbs> Someone should tell the reviewers if there are
packages which need reviews in order for features to progress.
19:10:20 <victorv> FYI netbeans-platform pkg is 100% ready to test,
but it is not in CVS due to
https://bugzilla.redhat.com/show_bug.cgi?id=510255
19:10:22 <buggbot> Bug 510255: medium, medium, ---, nobody, NEW,
Review Request: cobertura - a Java tool for calculating the test
coverage
19:10:46 <j-rod> perhaps a keyword should be added to review requests
that block features?
19:10:50 <jds2001> victorv: there's been no activity on that review
19:11:28 <Kevin_Kofler> Can we find a reviewer for that and then revisit?
19:11:43 <nirik> victorv: is that the last thing blocking it being testable?
19:11:47 <tibbs> I get the impression that folks think that reviewers
just come out of the aether.
19:12:14 <jds2001> tibbs: they don't? :D
19:12:18 <notting> tibbs: right, that's why we put the packages on the aethernet
19:12:35 * nirik groans.
19:13:21 <nirik> I don't know java packaging too well, but I can take
a stab at reviewing it.
19:13:27 <tibbs> Anyway, my point is that if someone wants to collect
a list of review tickets that are holding up features then we could
perhaps try to address them.
19:13:28 <victorv> nirik: the last thing is the netbeans pkg that is
in progress right now
19:13:39 <notting> so, hrm. it's not part of the default package set,
so i'd be willing to give a little leeway
19:13:55 <nirik> victorv: yeah, but that needs this new package first?
19:14:02 <jds2001> yeah, especailly since that review has been lingering
19:14:11 <tibbs> Or if the submitters want to actually indicate
somehow that individual tickets are needed for features to progress,
that would help as well.
19:14:16 <jds2001> not victorv's fault
19:14:25 <tibbs> But just assuming they're going to get done is not
going to work in general.
19:14:33 <jds2001> tibbs: that's noted on the feature page in question
19:14:40 <tibbs> That goes the wrong way.
19:14:52 <nirik> we could ask feature owners to add a
'neededforfeature' keyword or something.
19:14:54 <tibbs> A reviewer isn't going to read the feature page;
they're going to look at the review ticket.
19:15:17 <nirik> anyhow, I am willing to review this package, can we
vote on leaving this feature based on it getting testable asap?
19:15:40 <jds2001> sure, +1 to leaving it
19:15:56 <Kevin_Kofler> leave +1, drop -1
19:15:57 <victorv> nirik: netbeans pkg is already in Fedora. Need to be updated.
19:16:01 <j-rod> I'm fine with defer to next week
19:16:08 <nirik> victorv: right.
19:17:02 <nirik> +1 leaving for now.
19:17:05 <j-rod> +1 for leaving it in, if the bits are actually
testable by next friday
19:17:23 <notting> +1
19:17:24 <skvidal> +1 leaving for now
19:17:42 <jds2001> #agreed NetBeans feature is not dropped, pending
package review
19:17:59 <jds2001> NFSv4 default?
19:18:12 <Kevin_Kofler> steved: So what's the current status?
19:18:20 <Kevin_Kofler> The feature page was last updated on July 15.
19:18:24 <Kevin_Kofler> https://fedoraproject.org/wiki/Features/NFSv4Default
19:18:33 <jds2001> no
19:18:39 <jds2001> it was last updated today
19:18:49 <steved> all the kernel parts are in place... I have a
configuration file posted upstream...
19:18:51 <jds2001> (cur) (prev) 11:52, 7 August 2009 Steved (Talk |
contribs) (3,167 bytes)
19:19:00 <notting> ok, then -1 to dropping it
19:19:03 <steved> all thats left is to change the mount command
19:19:13 <nirik> -1 to dropping. Land as soon as you can.
19:19:16 <jds2001> -1 to dropping
19:19:29 <steved> is -1 good ? :)
19:19:34 <Kevin_Kofler> jds2001: Then he needs to fix the Last updated date.
19:19:38 <nirik> steved: yeah, in this case. ;)
19:19:39 <Kevin_Kofler> -1 to dropping.
19:19:42 <jds2001> steved: it is. :)
19:19:47 <steved> good!
19:19:55 * steved is working as hard as possible..
19:19:58 <Kevin_Kofler> But please keep in mind that the Last updated:
date needs updating, too, when you edit things. :-)
19:20:11 <steved> will do... thanks!
19:20:15 <jds2001> #agreed NFSv4 feature is not dropped
19:20:17 <j-rod> -1, keep it
19:20:40 <jds2001> Raduko Perl 6?
19:20:43 <nirik> -1 to dropping, it's done and landed now and should
be testable. (aside from a ppc bug that they are working hard on)
19:20:48 <Kevin_Kofler> -1 to dropping, it's already complete.
19:20:52 <jds2001> it seems to have landed.
19:20:58 <jds2001> -1 to dropping
19:21:06 <notting> yeah, -1.
19:21:08 <jds2001> Kevin_Kofler: not quite complete
19:21:14 <jds2001> Kevin_Kofler: a ppc bug remains
19:21:32 <nirik> one more so we cna move on?
19:21:58 <Kevin_Kofler> 2 more actually.
19:22:26 <nirik> I see 4 -1's... one more would be passing?
19:22:30 <jds2001> #agreed Raduko perl 6 feature is not dropped
19:22:36 <jds2001> oops
19:22:49 <nirik> j-rod: ?
19:23:00 <Kevin_Kofler> nirik: Oh, I thought you were talking about
the remaining features (we have 2 more to go).
19:23:22 <j-rod> sorry
19:23:23 <nirik> nope, was talking votes. :( looks like we may have lost quorum.
19:23:32 <j-rod> -1, keep raduko too
19:23:38 <jds2001> ok good
19:23:45 <nirik> next
19:23:46 <j-rod> rakudo, even
19:23:48 <jds2001> Thusnelda?
19:23:54 <jds2001> -1, keep it, it's landed
19:23:57 <Kevin_Kofler> -1 to dropping.
19:24:05 <Kevin_Kofler> Beta already in, worst case we can ship with that.
19:24:11 <nirik> yep. Keep it.
19:24:13 <Kevin_Kofler> And the final version is coming soon too.
19:24:22 <j-rod> -1 for drop, keep it in
19:24:35 <notting> right, -1 to dropping it
19:24:39 <nirik> cool. next?
19:24:48 <jds2001> #agreed Thusnelda feature is not dropped
19:25:02 <jds2001> YumLangPackPlguin?
19:25:12 <jds2001> the feature owner is reportedly on holiday
19:25:29 <jds2001> but even so, at 30% as of 7-24, this doesnt look good
19:25:51 <tibbs> I guess there's a review ticket on that one as well.
19:25:52 <nirik> I don't know how much of this has landed/is testable.
19:26:03 <tibbs> bug 512663
19:26:04 <buggbot> Bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=512663 medium,
medium, ---, nobody, NEW, Review Request: langpack-support - Meta
packages for Yum langpack support
19:26:09 <notting> -1, it hasn't landed
19:26:18 <notting> erm, +1 to drop, it hasn't landed
19:26:25 <nirik> yeah, I think dropping and punting to next cycle would be good.
19:26:29 <Kevin_Kofler> Is yum-plugin-langpacks anywhere?
19:26:35 <Kevin_Kofler> That's the code part.
19:26:41 <Kevin_Kofler> Without that, there's nothing in.
19:26:58 <j-rod> +1, next cycle
19:27:07 <jds2001> +1, next cycle
19:27:32 * jds2001 sees 3 votes
19:27:47 <jds2001> well, 4
19:27:54 <jds2001> if i count nirik's :)
19:28:03 <nirik> yeah
19:28:25 <jds2001> Kevin_Kofler: ?
19:28:40 <Kevin_Kofler> drop +1, I don't see yum-langpack-plugin anywhere.
19:28:51 <Kevin_Kofler> And the metapackage is not reviewed yet either.
19:29:10 <jds2001> #agreed Yum langpack plugin feature is deferred to F13
19:29:16 <jds2001> That's it for features
19:29:21 <f13> ok, I think it's time for the nick change :/
19:29:33 <jds2001> one remaining item on the agenda
19:29:45 <jds2001> f13: was wondering when you'd do that :)
19:30:16 <jds2001> anyhow, there's one remaining item
19:30:22 <j-rod> I'm fine with deferring libvdpau discussion to next
week, we're already a like 7 hours here
19:30:24 <jds2001> j-rod: it's not pressing, is it?
19:30:28 <jds2001> ok :)
19:30:34 <jds2001> that's what i was asking :)
19:30:40 <notting> hooray
19:30:49 <Kevin_Kofler> defer +1, I don't think we'll get a quorum
either way now and we're 30 minutes over time
19:31:01 <jds2001> anything else have anything that's world-ending?
19:31:28 <jds2001> guess not
19:31:30 <jds2001> #endmeeting
14 years, 9 months
- 1
- 0
F11: Bug in sh-4.0 source build-in command
by Dario Lesca
There is a bug in sh-4.0 source command:
Must specify directory (./file) for filename, without not work.
> sh-4.0# cd /tmp
> sh-4.0# echo aaa=ppp > sourcefile
> sh-4.0# ls -l sourcefile
> -rw-r--r-- 1 root root 8 3 ago 20:37 sourcefile
> sh-4.0# cat sourcefile
> aaa=ppp
> sh-4.0# . sourcefile
> sh: .: sourcefile: file not found
> sh-4.0# source sourcefile
> sh: source: sourcefile: file not found
> sh-4.0# echo $aaa
>
> sh-4.0# source ./sourcefile
> sh-4.0# echo $aaa
> ppp
> sh-4.0# exit
hope this help.
--
Dario Lesca <d.lesca(a)solinos.it>
14 years, 9 months
- 5
- 6
"Reign?"
by Richard W.M. Jones
Just went to download a Fedora ISO and I'm struck once again by how
peculiar the Fedora homepage has become:
http://fedoraproject.org/
(or screenshot: http://www.annexia.org/tmp/fedora.png)
What does the word "Reign" have to do with a Linux distro? If I knew
nothing about Fedora, what impression would I get from this page?
Now compare it to the Ubuntu home page:
http://www.ubuntu.com/
(or screenshot: http://www.annexia.org/tmp/ubuntu.png)
This clearly states what Ubuntu does, what benefits it has, and it's
immediately obvious how to download it.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
14 years, 9 months
- 4
- 3
Plan for tomorrow's (20090807) FESCo meeting
by Jon Stanley
Sorry for the late agenda, I completely had a communication failure
today :) Anyhow, here's the list of topics for tomorrow's (today's?)
meeting that will take place at 17:00UTC in #fedora-meeting on
freenode:
225 Bugzilla 484855 - Mediawiki Fedora-only patch
176 wiki information regarding FESCo seems to be outdated
210 Fedora packages as canonical upstreams
234 Feature submission freeze needs to be before Feature Freeze
239 Create bugs for every outdated package / release monitoring opt-out
240 Drop F12 Features that are not testable
238 Can libvdpau go in Fedora?
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor.
14 years, 9 months
- 1
- 0
F12 Alpha Blocker Bug Meeting: Friday 2009-08-07 @ 15:00 UTC (11 AM EDT)
by James Laska
What: Fedora 12 Alpha Blocker bug meeting
When: Friday, 2009-08-07 @ 15:00 UTC (11 AM EDT)
Where: #fedora-bugzappers on irc.freenode.net
A busy week for Fedora. The Alpha freeze has come and gone, testing
against the alpha test compose began, and the alpha compose is delayed,
but looming.
Please join us tomorrow as we scrub the list of bugs blocking the Alpha
release. Time permitting, the F12Beta and F12Blocker bugs will be
reviewed as well. For reference, the blocker bug links are below:
* F12Alpha -
https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Alpha&hide_resol...
* F12Beta -
https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Beta&hide_resolv...
* F12Blocker -
https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Blocker&hide_res...
Have an issue you'd like to propose for F12Alpha? Please consider the
following criteria when escalating an issue:
* Can this issue be fixed with a future rawhide update or is it
part of the media kit?
* Is this defect a high (or greater) severity [1] with no, or an
unreasonable, workaround?
* Does the presence of this bug dramatically reduce test coverage?
See you there!
James
[1] http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Severity
14 years, 9 months
- 1
- 0
Critical Path Packages - Enforcement?
by Kevin Kofler
Hi,
I have a few questions for the folks involved with the Critical Path
Packages proposal, as I'm still confused about the implementation details:
1. How will the policy be enforced? Will Bodhi withhold submitted updates
for packages in the depsolving hull of @critical-path until they get
approval from QA and/or rel-eng, like it currently does for security updates
until security team approval?
Assuming the answer to 1. is "Yes":
2. Will critical-path-gnome also get the same enforcement?
3. Will critical-path-kde also get the same enforcement?
4. Will critical-path-* for spins.fp.o spins also get the same enforcement?
If the answer to any of the above (1. to 4.) is "No", what kind of
enforcement will there be? When we discussed critical-path-kde today at KDE
SIG, we were very much confused about what exactly the practical
implications will be. I think it won't be of much use to define critical
path packages if that definition doesn't lead to some actual enforcement.
What we basically agreed on in KDE SIG (see also our meeting log [1]) was:
* The KDE spin being one of the primary spins, critical-path-kde should get
the same kind of enforcement as critical-path-gnome. (We have no official
opinion about stuff like critical-path-xfce as that's out of the scope of
our SIG.)
* It doesn't make much sense for us to define critical path packages if it
won't have any actual practical implications. (We already know what's
critical to what extent, so a purely-informative critical-path-kde won't be
of much use to us.)
But we need the clarification I requested above to make any further
decisions.
Another open question is who is going to QA critical-path-kde, as we still
don't have a dedicated tester in KDE SIG. Anybody volunteering to be a
tester for KDE SIG is requested to talk to us on the #fedora-kde IRC chan
and/or the fedora-kde mailing list. Being a tester has a much lower barrier
to entry than most other forms of contribution, you just need some HD space
to install test systems to (ideally, you'd have Rawhide, Fn and Fn-1 on at
least one machine each, but even just testing one release is helpful) and
some spare time. No programming, drawing, technical writing etc. skills
required. I will post a call for help to the fedora-test-list as well. (Note
that we do have a KDE SIG member in rel-eng (rdieter), so that part is
covered.)
Kevin Kofler
[1] http://urlx.eu/_Mzk4MQ
14 years, 9 months
- 3
- 3