=== Pilif12p is now known as Pilifhashw
=== sanchaz is now known as sanchaz-away
=== Pilifhashw is now known as Pilif12p
[02:01] <Keybuk> Coo, the UDS hotel is strangely dead without the kernel team camped around the pool
[02:03] <lifeless> ;)
[02:06] <Keybuk> lifeless: you're home already, or in airport limbo?
[02:07] <lifeless> home
[02:07] <lifeless> fucked, but home
[02:09] <Keybuk> yay, at least you're there :)
[02:12] <lifeless> yeah
[02:13] <lifeless> Lynne's happy :)
[02:13] <Keybuk> hwhw
[02:13] <Keybuk> say hi from me
[02:15] <lifeless> kk
[02:21] <ScottK> debfx: It turns out that there's a new tool for archive admins to process syncs so they don't often look at the bug queue anymore.  We discussed at UDS extending it to cover backports so those will get quickly and easily processed too.
[02:30] <slangasek> ScottK: huh, really?  What tool is this?
[02:30] <slangasek> I guess I missed a memo
=== oubiwann-away is now known as oubiwann
[03:31] <ScottK> slangasek: sync-helper I think.
[03:31] <ScottK> (in the archive admin tools)
[03:31] <ScottK> slangasek: It wouldn't hurt if you could have a look at pending backports requests if you have a moment though.
=== solid_liquid is now known as solid_liq
=== manusheel is now known as manusheel_afk
[08:32] <dholbach> good morning!
=== Pendulum_ is now known as Pendulum
=== sanchaz-away is now known as sanchaz
=== almaisan-away is now known as al-maisan
=== drizztbsd_ is now known as drizztbsd
=== xfaf is now known as zul
=== al-maisan is now known as almaisan-away
[12:12] <pitti> Good morning
[12:15] <dholbach> hey pitti
[12:16] <pitti> hey dholbach, back home?
[12:16] <dholbach> pitti, yep
[12:28] <pitti> cjwatson: could we re-enable daily CD cronjobs, or do these need some natty update first? (I mostly want to track CD size now)
[12:30] <cjwatson> pitti: can't enable them yet, no
[12:31] <cjwatson> pitti: two reasons: need to finish merging installer before they'll be useful; and I really want to do the ports merge before we start
[12:34] <pitti> cjwatson: okay, no problem
[12:50] <Yaron-Heb> Hey guys, There is some package I want to get back in Ubuntu
[12:50] <Yaron-Heb> What would be the best way to do it?
[12:51] <geser> which package? is it in Debian?
[12:52] <cjwatson> debfx,ScottK: I've done those backports now; sorry for the long delay
[12:52] <cjwatson> (but yes, tool support would help make it more timely in future)
[12:53] <ScottK> cjwatson: Thanks.
[12:54] <Yaron-Heb> yes it is
[12:54] <cjwatson> Yaron-Heb: which package?
[12:54] <Yaron-Heb> geser: yes it is...
[12:55] <Yaron-Heb> geser: bidiui, included in Karmic
[12:55] <d1b> hi guys quick question, how do i get dpkg-buildflags to take options from my config file --> the man page doesn't document how they should be setup out and CFLAGS= -O2 etc. doesn't seem to work
[12:55] <Yaron-Heb> geser: https://bugs.launchpad.net/thunderbird/+bug/649341
[12:56] <ubottu> Launchpad bug 649341 in bidiui (Ubuntu) "Please update from debian" [Undecided,New]
[12:56] <cjwatson> d1b: the man page suggests 'SET CFLAGS -O2' - have you tried that?
[12:56] <Yaron-Heb> cjwatson: same...
[12:56] <d1b> cjwatson: that isn't in mine i think :)
[12:56] <d1b> thanks
[12:57] <cjwatson> Yaron-Heb: subscribe ubuntu-archive to that bug report
[12:57] <d1b> cjwatson: it works :)
[12:57] <Yaron-Heb> cjwatson: i will, thanks
[12:57] <cjwatson> Yaron-Heb: (and mark the upstream task invalid please - it's not an upstream bug)
[12:57] <geser> Yaron-Heb: I see it got removed because it's an unsupportable mozilla extension
[12:57] <cjwatson> Yaron-Heb: we probably won't do it in maverick though
[12:58] <Yaron-Heb> cjwatson: fine, I will, thank you
[12:58] <cjwatson> oh, it's one of those, hmm
[12:58] <cjwatson> well, that was a decision by the Ubuntu Mozilla team, I don't want to override them as an archive admin ...
[12:58] <cjwatson> https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/extension-list
[12:58] <cjwatson> so I guess you'll actually need to ask #ubuntu-mozillateam
[12:59] <geser> cjwatson: it's also on sync blacklist
[12:59] <cjwatson> yes, I know
[12:59] <Yaron-Heb> cjwatson: I added them, hope its ok
[12:59] <cjwatson> Yaron-Heb: well, I meant the IRC channel, but OK
[13:00] <cjwatson> I think I'll actually have to unsubscribe ubuntu-archive from the bug - we can't do anything without the Mozilla team's say-so
[13:00] <cjwatson> sorry for the initial incorrect advice
[13:01] <cjwatson> I've commented on the bug to that effect
[13:04] <Yaron-Heb> Colin J Watson: Thank you! I'll go talk to the channel
[13:07] <Yaron-Heb> I can't unsubscribe ubuntu-archive, I'm not a member...
[13:09] <ScottK> Yaron-Heb: I believe he said he'd take care of that part.
[13:09] <cjwatson> I already did.
[13:09] <Yaron-Heb> thanks... my bad
=== deryck_ is now known as deryck
[13:47] <mterry> james_w, what was the blueprint for the 'automatic packaging' session?  Not sure I ever uploaded my notes/work-items from that session or not.
[13:47] <mterry> Can't find it now
[13:59] <james_w> mterry, https://blueprints.edge.launchpad.net/ubuntu/+spec/appdevs-community-n-auto-generate-packaging
[14:03] <mterry> james_w, awesome.  OK, good, I did add notes to wiki already.  I just updated the whiteboard with the action items from the meeting.  You might want to add high level overview to the Proceedings wiki page
[14:03] <james_w> mterry, thanks
[14:04] <james_w> mterry, https://edge.launchpad.net/~pkgme-devs is the team I created for the mailing list if you want to join
[14:06] <mterry> james_w, done
[14:11] <MattJ> You know those people who you switch to Ubuntu, but they jump at any chance to say "I knew I should have stuck with Windows"?
[14:11] <MattJ> There's a minor issue, but perhaps it's better in 10.10, I haven't checked
[14:11] <MattJ> When update manager picks up updates, but doesn't download until later, sometimes package versions may be out of date (security upgrades)
[14:12] <MattJ> It throws up an unfriendly dialog saying there has been an error getting packages
[14:12] <ebroder> pitti: why does gnome-system-tools depend on perl at all? i can't find any perl code in there
[14:12] <pitti> ebroder: system-tools-backends is written in Perl
[14:12] <MattJ> This seems perhaps like a usability issue, in that it's potentially something an everyday user could encounter but not understand
[14:14] <ebroder> pitti: and the backends need a perl gnome stack? eww
[14:15] <pitti> ebroder: at least it depends on perl
[14:15] <micahg> MattJ: please file a bug against update-manager
[14:15] <MattJ> micahg: Thanks, shall do
[14:15] <pitti> ebroder: we could do some research to split out the necessary perl modules for that, but it's moot, since we want to replace it with the gnome 3 user admin tool anyway
[14:16] <ebroder> pitti: at least on my lucid machine, gnome-system-tools *does* depend perl (which appears to be bogus), and system-tools-backends *doesn't*
[14:16] <pitti> that sounds wrong indeed
[14:18] <ebroder> pitti: meh. it's a moot point if we can get the gnome 3 tools in
[14:18] <pitti> ebroder: I don't see why we wouldn't get it in
[14:22] <MattJ> I guess finding bugs in Launchpad while reporting bugs is just part of the process :)
[14:42] <BUGabundo> G'afternoon
[14:44] <fagan> afternoon BUGabundo
=== dendro-afk is now known as dendrobates
=== manusheel_afk is now known as manusheel
[15:21] <pitti> lamont: will anything blow up if I add a new binary dependency to pkgbinarymangler?
=== yofel_ is now known as yofel
=== almaisan-away is now known as al-maisan
[15:37] <cjwatson> jdstrand: I took an action at UDS to merge the dhcp3 changes into isc-dhcp.  I just realised that I didn't check that with you, as the last uploader of dhcp3, to see if you were already doing it.  Do you mind?
[15:37] <lamont> pitti: shouldn't - though said dependency effectively becomes build-essential.  Therefore, proceed with care
[15:37] <lamont> pitti: it's not held anymore
[15:38] <lamont> so also, don't break everything or I'll have to come visit you :-p
[15:38] <pitti> lamont: in particular it's optipng; it might pullin linpng12-0
[15:38] <pitti> "pulling in libpng12-0"
[15:38] <pitti> (uh)
[15:39] <pitti> lamont: for the actual operation I'll test case all this; I just wasn't sure whether it's using upgrade or dist-upgrade, the former would hold it back
=== dendrobates is now known as dendro-afk
[15:45] <lamont> pitti: dist-upgrade is the only command that ever makes any sense for apt-get.  that upgrade thing you speak of is ancient history and wrong
[15:46] <pitti> lamont: heh, ok; thanks for confirming
[15:46] <pitti> well, it avoids structural changes and thus accidental removals etc.?
[15:46] <lamont> pitti: boring
[15:47] <malte> Hi, I'm trying to port appmenu to Gentoo and I'm stuck on the GTK+ part (I'm not a gentoo developer, nor do I know C, I'm just someone who likes playing around with Gentoo). When I apply the 043_ubuntu_menu_proxy.patch, the build fails with the following error: http://pastebin.ca/1978783 and I can't figure out how to fix it.
=== dendro-afk is now known as dendrobates
=== dholbach_ is now known as dholbach
[16:04] <cjwatson> malte: looks like a bug in the patch to me; there should be a declaration for ubuntu_gtk_menu_shell_activate_mnemonic in gtk/gtkmenushell.h, I think
[16:04] <cjwatson> malte: #ubuntu-desktop would be able to correct me if I've made a mistake there
[16:05] <malte> cjwatson: thanks, I'll try it there
[16:06] <cjwatson> malte: the Ubuntu build log shows warnings for this, but not errors
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
[16:07] <cjwatson> different compiler option defaults, I guess
[16:07] <malte> cjwatson: I even tried to apply all the ubuntu patches, which also failed. So it might be a build option, or compiler option as you said.
=== xfaf is now known as zul
=== deryck is now known as deryck[lunch]
=== elkybirthday is now known as elky
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
[16:58] <Aquina> Are you also receiving e-Mails like that one: http://pastebin.com/eAgGNjjh (by a person named Jason)? It's the third time now i got such a message.
[16:59] <pitti> Aquina: I didn't, but it does seem to be sincere; perhaps point the guy to https://wiki.ubuntu.com/ContributeToUbuntu and to #ubuntu-motu?
[17:09] <pitti> ScottK, barry: I'm curious, I guess the plan is to default python to 2.7? right now it seems we install both 2.6 and 2.7, and 2.6 is still the default
[17:10] <ScottK> pitti: The plan is to enable 2.7 and make an assessment of it's readiness to be default once we've got all the needed rebuilds done.
[17:11] <ScottK> On a related note, just upload what I hope is the fix for python2.7 FTBFS on powerpc.
[17:11] <ScottK> upload/uploaded
[17:18] <pitti> james_w: question, did you send the polkit hang fix upstream? I can't find it in the bugs
[17:18] <pitti> james_w: I'd like to add it to the Debian package, too
=== deryck[lunch] is now known as deryck
[17:28] <james_w> pitti, I did. Did I not link the bug reports?
[17:28] <pitti> james_w: one has an upstream bug, but there's no patch
[17:28] <james_w> pitti, http://bugs.freedesktop.org/show_bug.cgi?id=30515
[17:28] <ubottu> Freedesktop bug 30515 in daemon "Race means that client can get no response from agent" [Normal,New]
[17:29] <james_w> pitti, if you can reproduce then help with forward porting would be appreciated
[17:30] <pitti> james_w: I can't reproduce, but if it has shown to work, I'm happy to throw it into Debian git
[17:32] <james_w> pitti, confirmed to work in the version we have in Ubuntu
[17:33] <pitti> james_w: cool, thanks
=== al-maisan is now known as almaisan-away
[17:35] <cjwatson> hmm.  I suspect I ought to take a local copy of the current dhcp3-* debs before testing an upgrade to isc-dhcp 4 :-)
[17:36] <bilalakhtar> james_w: Could you please merge https://code.launchpad.net/~bilalakhtar/bzr-builddeb/add-natty/+merge/39688 ? Someone reviewed it but hasn't been merged yet :( BTW, pitti: would you find bug #668764 suitable for an SRU?
[17:36] <ubottu> Launchpad bug 668764 in bzr-builddeb "Add Natty to the list of known distros" [Undecided,In progress] https://launchpad.net/bugs/668764
[17:36] <bilalakhtar> Since it is currently a blocker for anyone who wishes to use UDD for merging
[17:39] <bilalakhtar> Not exactly a blocker, but 'it would make a major feature almost useless, since most devs may be working on natty throughout the cycle
[17:39] <LLStarks> pitti, is there a log or transcript of the ubuntu footprint panel?
[17:39] <LLStarks> from uds
[17:40] <pitti> LLStarks: it should still be in gobby
[17:40] <pitti> LLStarks: but I did the writeup yesterday to clean it up
[17:40] <LLStarks> i'm curious to know whether apt-sync and delta debs were seriously considered
[17:40] <cjwatson> I just edited /usr/share/pyshared/bzrlib/plugins/builddeb/util.py to add it locally, TBH :-)
[17:40] <pitti> LLStarks: so now it's the whiteboard in https://blueprints.edge.launchpad.net/ubuntu/+spec/performance-desktop-n-install-footprint
[17:40] <cjwatson> LLStarks: those don't affect installation size
[17:40] <ebroder> or cd size
[17:40] <pitti> LLStarks: they weren't, and they don't affect CD/install size
[17:40] <pitti> heh, snap
[17:41] <LLStarks> is that the excuse to prevent delta debs from ever getting its own approved blueprint or push it back year after year?
[17:41]  * pitti raises the "current potential savings" bar to 32.5 MB
[17:41] <pitti> LLStarks: it's not an excuse, it's simply unrelated
[17:42] <pitti> and delta debs not making it is primarily a question of manpower, I guess
[17:42] <cjwatson> and "prevent ... from ever getting its own approved blueprint" is simply not true!
[17:42] <cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-rsync-based-deb-downloads
[17:42] <cjwatson> it didn't happen due to time, not due to some conspiracy on the part of UDS schedulers ...
[17:43] <cjwatson> I'd like to see it happen; it's just a big project that nobody with the necessary skills has yet picked up
[17:44] <bilalakhtar> pitti: Did you read what I said above?
[17:44] <pitti> bilalakhtar: I'd prefer if james_w could look at bzr-builddeb, it's his baby
[17:44] <bilalakhtar> pitti: You're the SRU guy!
[17:45] <bilalakhtar> hmm, yes, he woudl be the person to ask
[17:45] <pitti> bilalakhtar: as for the SRU, I'm a bit torn -- I don't like people doing natty uploads on maverick
[17:45] <pitti> bilalakhtar: but I realize that a lot of people do anyway, so I won't veto against it
[17:45] <pitti> so if someone uploads it, I'll process it
[17:46] <bilalakhtar> pitti: We have sessions and classes advising people to move to UDD, and now, we want the process to be as streamlined as possible
[17:46] <ebroder> bilalakhtar, pitti: don't those sorts of things usually get handled in backports?
[17:46] <ebroder> (i.e. adding dev release support to debootstrap, etc)
[17:46] <bilalakhtar> I have seen that bzr-builddeb has matured enough to be my preferred work environment
[17:46] <pitti> yeah, bzr bd is pure ♥
[17:47] <bilalakhtar> ebroder: Isn't dev release support in debootstrap always?
[17:47] <ebroder> bilalakhtar: i feel like i usually see it get uploaded to the dev release, then backported to stable releases. but i could be misremembering
[17:47] <ScottK> bilalakhtar: It was this time, but usually we fine out the name too late to do that.
[17:47] <ScottK> fine/find
[17:48] <bilalakhtar> yup
[17:48] <bilalakhtar> I think we should have the name finalized quite soon
[17:48] <ebroder> pitti: i don't see it on the spec - are you planning to deal with ubuntu-keyring's semi-bogus gnupg dep?
[17:48] <cjwatson> is that a prediction or a wish?
[17:48] <bilalakhtar> but that is a separate issue
[17:48] <cjwatson> Mark usually tells us the name around beta
[17:49] <mterry> pitti, what's the syntax for having two people assigned to a work item?
[17:49] <mterry> (if there is one)
[17:49] <pitti> ebroder: not on my list so far; it wouldn't help for the default install, but if that dependency is getting into the way, we can certainly drop it
[17:49] <cjwatson> and he normally does it as part of an announcement which includes thoughts about the general style of the next release, which makes it hard to announce any earlier with the current model
[17:50] <pitti> mterry: there isn't; a WI should be small enough for one person; split it into two WIs then
[17:50] <mterry> k
[17:50] <ebroder> pitti: it would be convenient for me, but if you weren't already planning to do it i can make it my problem
=== dendrobates is now known as dendro-afk
[17:52] <james_w> bilalakhtar, merged, thanks
[17:52] <bilalakhtar> james_w: would this fix be fit for an SRU?
[17:52] <james_w> I think so, if the SRU team is happy
[17:54] <bilalakhtar> james_w: hmm, will propose a patch and then see what the other devs think, In any case, I would need sponsorship
=== dendro-afk is now known as dendrobates
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
[18:25] <Quantum_Ion> How do you set compile flags for ubuntu linux ?
[18:38] <fagan> Quantum_Ion: this channel is for development of ubuntu you should ask that on #ubuntu-app-devel
[18:39] <Quantum_Ion> fagan, Thanks
[19:01] <slangasek> psusi: ping
[19:18] <psusi> ubiquity doesn't somehow use udebs does it?  those are only part of d-i on the alternate cd right?
[19:21] <psusi> cjwatson: you've assigned a few bugs to grub-installer that were originally ubiquity crashing.. why?  isn't grub-installer part of d-i, and so not used on the livecd?  and whether installing grub failed or not, shouldn't ubiquity not crash?
[19:21] <chirag> hi everyone
[19:21] <chirag> I am using Lucid 10.04
[19:22] <chirag> I am having tough time installing my inbuilt webcam
[19:22] <chirag> can anyone please help
[19:22] <chirag> ?
[19:22] <fagan> chirag | !support
[19:22] <Pici> chirag: The support channel is #ubuntu, #ubuntu-devel is for development.
[19:23] <Pici> fagan: !foo | bar
[19:23] <chirag> ok
[19:23] <fagan> oh whoops Pici I always get that mixed up
[19:40] <pitti> ScottK, barry: do you happen to know whether dh_python{23} still need the old XS-Python-Version: tags? the manpage doesn't mention these
[19:53] <micahg> ScottK: I just thought of something re -backports being pinned lower, don't we have to make -backports only build from -updates then unless a version in -backports is requested?
=== hanska is now known as dapal
[20:10] <ebroder> micahg: not if we teach apt to use backports to satisfy dependencies for packages being installed from backports
=== transitlogger is now known as apachelogger
[20:20] <micahg> ebroder: no, that's the point, if we don't want people installing from all of backports by default, we should probably build from -updates only unless a version from backports is specified
[20:21] <ebroder> You can't do that, because you sometimes need to backport build-deps (i.e. dh 7 was backported to hardy-backports)
[20:21] <micahg> ebroder: that's the second part of what I said
[20:22] <ebroder> micahg: I'm not sure I understand what you're suggesting. That you have to explicitly ask for build-deps to get pulled from -backports somehow?
[20:23] <micahg> ebroder: yes, that'll prevent extra backports from being used (similar to debian experimental)
[20:24] <ebroder> micahg: I'm having a hard time believing we need to be that strict. Especially given that we generally only backport leaf packages (which excludes libraries in general)
[20:24] <ebroder> And it seems like teaching soyuz how to deal with that would make the task a lot more substantial
[20:39] <pitti> skaet: hello! thanks for the initial changelog licensing inquiry
=== sconklin1 is now known as sconklin
=== warp10` is now known as warp10
[20:58] <ScottK> micahg: I think that you can't handle that a build time.
[20:59] <ScottK> pitti: The preferred form is X-Python-Version (and X-Python3-Version), but XS-Python-Version is still supported as an alternative.  Debian Python Policy discusses this.
[21:00] <pitti> ScottK: ah, so it doesn't actually need to go into Sources.gz any more?
[21:00] <ScottK> pitti: That's the idea. XB-P-V is also no longer required.
[21:01] <ajmitch> ScottK: is there any documentation about switching to dh_python2 from pycentral/pysupport?
[21:01] <pitti> ScottK: so you do a content-based detection/decision which packages to rebuild now?
[21:01] <ScottK> ajmitch: There is, but don't ask me where.  barry knows more about documentation than me (I think).
[21:02] <ScottK> pitti: That's all we've ever been able to do.  XB-P-V coverage was never complete or accurate enough to be really useful.
[21:02]  * ajmitch looked on the debian wiki & didn't find it, mailing list threads seemed a bit spread out to be useful
[21:09] <jdstrand> cjwatson: feel free to do the merge. I don't mind
[21:14] <pitti> ScottK: ok, thanks; what's the X-P-V: in the Source: part good for then?
[21:14] <pitti> ScottK: I just packaged "scour" and didn't specify it, and it was clever enough to figure out "2.6, 2.7"
[21:14] <ScottK> pitti: It's used in conjunction with pyversions to figure out what python versions to build for.  If not present it will fall back to all.
[21:15] <ScottK> This will work, but it's better to specify, IMO.
[21:15] <pitti> ScottK: as "2.6, 2.7" or "all"?
[21:15]  * pitti hopes for the latter
[21:15] <ScottK> 2.6 and 2.7 are all supported versions.
[21:15] <pitti> ScottK: I mean, "X-Python-Version: all" will still work?
[21:16] <ScottK> Yes, but the preferred form would be >= 2.4 (or whatever the lowest version it supports is)
[21:16] <pitti>  ah, right; thanks!
[21:16] <ScottK> We're trying to push towards more specificity and less magic in Python Policy.
[21:17] <pitti> >= 2.6 sounds fine to me
[21:17] <pitti> I just don't want to hardcode the list of supported versions
[21:17] <ScottK> Agreed.
[21:17] <pitti> but specifying the minimum required version makes absolute sense
[21:17]  * sense agrees
[21:18] <pitti> sense: :)
[21:18] <sense> :)
[22:05] <ScottK> OK.  Python2.7 finally built on all archs.
[22:06] <ebroder> \o/
[22:09] <fagan> ScottK: is there anything in 2.7 that will break anything made with 2.6
[22:10] <ScottK> Yes.
[22:18] <geser> ScottK: do you know the status of py2.7 support in python-support? (I don't know if python-central needs changes too)
[22:18] <ScottK> geser: both need changes.  I'm reviewing barry's proposal for -support right now.
[22:18] <geser> ok
[22:36] <ari-tczew> OdyX: around?
=== tkamppeter_ is now known as tkamppeter
[22:52] <psusi> slangasek, ping
[23:01] <bdrung> which tools are used to create the official ubuntu live CDs?
[23:01] <ebroder> bdrung: livecd-rootfs does most of the heavy lifting
[23:02] <ebroder> (err, the livecd-rootfs package, that is)
[23:02] <slangasek> psusi: hi there
=== cmagina-afk is now known as cmagina
[23:03] <slangasek> psusi: you may have seen that I've reverted your changes to bug reports on powernowd.  Please don't close bugs with the argument "you shouldn't use this package".  If a package shouldn't be used, please *get it removed from Ubuntu* first...
[23:03] <bdrung> ebroder: thx
[23:04] <psusi> slangasek, I filed a bug in debian but I am not familiar with their practices so perhaps you could check it to make sure I did it right... it is bug #602052.  Also should I file a bug requesting it be dropped from ubuntu?
[23:04] <ubottu> Launchpad bug 602052 in MVHub "google ads mess up side bar with IE6,7,8" [High,Fix released] https://launchpad.net/bugs/602052
[23:05] <psusi> slangasek, also I'm pretty sure that half of those people didn't even have the package installed and that the bug only got assigned to the powernowd package because the kernel mentions the word powernow
[23:05] <chris1> i have a java question, and i didn't know where to ask so i thought someone here must know this. How does java handle allocating objects when memory is full? does it throw an exception? is the returned object null? does anyone happen to know? sorry for being offtopic..
[23:05] <slangasek> psusi: yes, please also file a bug in LP against the package in Ubuntu, providing a similar rationale, and subscribe ubuntu-archive
[23:06] <slangasek> psusi: sure, some of those bug reports may be bogus, but we shouldn't *assume* they're bogus... removing the package may be the best way to address this, I just want to make sure the package actually gets removed from Ubuntu rather than lingering with no attention to the bugs
[23:06] <slangasek> the bugs themselves still exist until we've removed the package
[23:07] <psusi> will do.. iirc I had reassigned a few of the bugs to linux where it seemed that might do some good... you didn't reverse those did you?  the rest just seemed like there was no point in having them around since they were reported years ago and have seen zero activity and certainly never will
[23:07] <slangasek> no, I only reversed the ones I could find, which is the ones still assigned to powernowd :)
[23:08] <psusi> some of them I didn't bother reassigning because it seemed likely that the op had moved on and could not provide any additional info required to properly triage
[23:08] <psusi> but I mentioned that if they did come back, they should do so
[23:09] <cjwatson> psusi: because I know what I'm doing :-)
=== dendrobates is now known as dendro-afk
[23:09] <psusi> I've been on a bit of a triaging spree the last few days... a bug should not sit there in the new or confirmed state for years with no attention... it needs triaged if possible, and closed otherwise
[23:09] <cjwatson> psusi: ubiquity uses grub-installer, albeit not as a udeb - the source is incorporated into ubiquity, and crashes in grub-installer need to be fixed there
[23:09] <psusi> cjwatson, ahh, yes... re: grub-installer... it only builds a udeb, so isn't it only used in d-i on the alternate cd?
[23:10] <slangasek> psusi: btw, since powernowd has an ubuntu revision number in Ubuntu, even if the Debian bug is acted on quickly, this doesn't automatically translate to a removal from Ubuntu
[23:10] <cjwatson> jdstrand: thanks
[23:10] <psusi> ohhh boy... that's weird... so ubiquity build-depends on grub-installer and links in some of it?  I see...
[23:11] <slangasek> psusi: er, "and closed otherwise" - I don't consider that to be a representative description of the standard bug-handling policies in Ubuntu
[23:11] <slangasek> at *most*, the policy is to mark the bug "incomplete" if there's missing information, and give the submitter an opportunity to supply whatever information is missing
[23:11] <psusi> slangasek, seems to be what the "incomplete" state exists for
[23:11] <slangasek> well, these bugs were closed as "invalid", not "incomplete" :)
[23:12] <cjwatson> psusi: no, there's a script in the ubiquity source package that fetches updated source packages and copies them.  I tried various approaches and settled on that.  Regardless, please don't undo any actions I've taken where I've reassigned bugs from ubiquity to a d-i component
[23:12] <psusi> well, they should have been incomplete long ago so I guess I kinda was trying to hurry the process along a bit... can always move it back if they respond, and I subscribed to them all
[23:12] <cjwatson> psusi: please don't close them unless you can prove they're fixed
[23:13] <cjwatson> otherwise I'm going to have to spend hours reopening
[23:14] <cjwatson> http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2009-02-27-bug-triage-rants.html and http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2009-03-05-bug-triage-redux.html are summaries of my thoughts on bug triaging
[23:14] <psusi> well, they should be incomplete then at least if more information is needed... if it can't get to triaged then what's the point?  some guy saying something crashed once years ago and there's no idea of why just seems to clutter things up and prevent attention going to bugs that can be fixed
[23:14] <cjwatson> and, TBH, the distinction between Confirmed and Triaged (and for that matter often New) is not all that helpful to me as a developer
[23:15] <cjwatson> so if you find bugs where all the is haven't been dotted and the ts haven't been crossed, it's because I find it a net waste of time
[23:16]  * slangasek prefers crossing the ɨs and dotting the ṫs
[23:16] <psusi> if there is enough information there to understand the problem and contemplate a fix, it should be triaged shouldn't it?  and otherwise, it doesn't do anybody any good to rot as new for years
[23:16] <micahg> psusi: currently bug policy if a bug is new or confirmed, one should attempt to reproduce before commenting/changing status on the bug
[23:16] <cjwatson> if you have a different opinion and want to help get the bugs into a state where they have clearer information, that's fine, but I would prefer it not to create lots of bug-mail noise, so if you could try to stick to the bugs that really have very little information indeed, I would prefer that
[23:16] <cjwatson> psusi: the purpose of bug reports is to improve the software, not to improve the bug statistics; I try to spend time fixing bugs rather than changing bug statuses
[23:17] <slangasek> psusi: "it should be triaged" - probably, but then why are you marking them invalid instead of marking them triaged?
[23:17] <cjwatson> like I say, if you want to help out with that that's great, I just want not to have to spend time cleaning up afterwards as I often seem to have to do
[23:17] <psusi> yea, I've managed to get several nicely reformatted to clearly describe the problem and what's likely needed to fix it and marked them as triaged.. much more handy to see all that in the subject and description instead of having to read all of the comments to get the picture
[23:19] <psusi> slangasek, because there was insufficient information to triage... I suppose incomplete would have been better for that batch, then either letting them expire or reassigning them to linux if that is the case, or if it really is a bug in powernowd, probably should end up as wontfix
[23:19] <cjwatson> IMO closing bugs should be a task for a developer of the package rather than a bug triage function
[23:20] <cjwatson> (and if there isn't a developer right now, they should be left open until there is - unless they really are completely uninformative)
[23:20] <slangasek> psusi: I agree, that should be incomplete instead then.  But some of these bugs clearly *did* have enough information to reproduce them - like the ones saying the package fails to install, or that LSB info is missing from the init script
[23:20] <psusi> cjwatson, I understand that... but it just seems to do more harm than good to have tons of ancient bugs cluttering up the system that have not, and and will not be fixed... why leave a reporter hanging and feeling totally ignored for years if it really won't be fixed?
[23:21] <micahg> cjwatson: I agree if there's enough information to warrant it being triaged
[23:21] <slangasek> because they've already been ignored for years and already feel that way; invalidating a valid bug only compounds the feeling
[23:21] <cjwatson> because it's even worse to leave them hanging for a while and then close their bug without fixing it
[23:21] <cjwatson> what slangasek said
[23:21] <cjwatson> micahg: from what slangasek is saying, there was in some of these cases
[23:22] <maco> i'm increasingly agreeing with cjwatson on triage not being suitable for non-developer-types to be thrown into
[23:22] <micahg> cjwatson: right, I was commenting on the principle, not this case in particular
[23:22] <cjwatson> psusi is a developer type mind you (elsewhere), so I don't really understand what's going wrong here
[23:23] <micahg> cjwatson: different teams have different bug processes
[23:23] <cjwatson> true
[23:23] <slangasek> cjwatson: in the case of powernowd, I think it's a question of "due process" - if the package really shouldn't be used, we need to make sure we really get it out of the distro, *then* close the bugs out
[23:24] <cjwatson> the Debian BTS rule is that you don't close other maintainers' bugs; unfortunately we never really instituted a proper equivalent of that when removing the maintainer lock
[23:24] <cjwatson> but I think the general principle is sound
[23:24] <cjwatson> slangasek: right, I have the same problem with closing grub bugs
[23:25] <psusi> slangasek, true...
[23:25] <cjwatson> as long as people can still install it in the current development release, closing the bugs is mostly futile - in many cases we'll just get new ones
[23:25] <psusi> cjwatson, that works in debian because very package has a maintainer... that isn't so with ubuntu
[23:25] <cjwatson> psusi: sure, but did you read the rest of what I said?  it doesn't seem like it :-(
[23:25] <cjwatson> bugs staying open is not in and of itself a failure
[23:26] <maco> you know that greasemonkey script that shows people's team icons (bug control, motu, core dev) next to their names in lp? how about a rule that says triagers shouldnt close bugs that have a member of ~ubuntu-dev subscribed directly or have anyone set in the Assigned field?
[23:26] <maco> cjwatson: the bugs of yours that go missing... are they ones you have assigne yourself to, or are you using teh whole package:grub queue as your queue?
[23:26] <cjwatson> there may be other factors that make it a problem, but in and of itself, a bug should stay open 'til it's either fixed, shown to be not a bug, etc.
[23:26] <psusi> staying in the new state forever seems bad to me... a few months, sure.. but when it's been 3 releases since the last update, and it still hasn't gotten to the point where it correctly describes a bug and can be worked on... it seems to be doing more harm than good ot me
[23:27] <cjwatson> psusi: please accept that other developers have different practices
[23:27] <cjwatson> psusi: and that taking this approach can get in other people's way
[23:27] <cjwatson> maco: they don't go missing as such, but I get more bug mail than I can process
[23:27] <micahg> cjwatson: if you have a few packages you would like triagers to stay away from, please give me a list and I"ll get it into the BugSquad docs
[23:27] <cjwatson> micahg: no, this is the wrong answer
[23:27] <cjwatson> I don't want to have to explicitly blacklist a load of stuff
[23:27] <micahg> cjwatson: I was hoping you'd say that :)
[23:27] <cjwatson> I want triagers to get a clue :-)
[23:28] <maco> cjwatson: by "go missing" i meant when someone invalidates a bug that you have an intention of fixing
[23:28] <kklimonda_> "don't touch Colin's packages"? ;}
[23:28] <cjwatson> missing the point!
[23:28] <maco> and then it disappears from lp searches
[23:28] <micahg> cjwatson: right, so we're trying to revise the mentoring program, but some people wander aimlessly and don't ask questions
[23:28] <cjwatson> what is the purpose of bug triage if it is not to help developers?
[23:28] <cjwatson> and if it is to help developers, why do bug triagers work against what developers want?
[23:28] <cjwatson> I think it is because bug triage has been made an end in itself, rather than a means
[23:28] <maco> micahg: his complaint has been before that triagers will look at bugs where he has said exactly what is wrong and how he needs to fix it, and triagers will ignore that comment and go and "is it fixed yet? oh you didnt answer. *invalid*"
[23:29] <cjwatson> this problem is not just mine, and making it about me misses the point.  (yes, I realise that other Ubuntu developers have other practices, and I'm entirely happy for them to follow them)
[23:29] <cjwatson> (but I am also not unique)
[23:29] <micahg> maco: right, I remember the post, we try to tell people they have to reproduce when they come to us, but we have trouble with the people who never come to meetings and don't keep up with the latest policies
[23:30] <psusi> well from the triage docs, I understand the goal to be to get a bug into a point where it can convey to the developer what the problem is so they can work on it and mark it as triaged... but it seems that all too often nobody touches it and it just rots for years in the new state doing nobody any good and never will since no developer can look at it and figure out what he needs to go fix
[23:30] <cjwatson> making it about a list of individual packages also misses the point
[23:30]  * maco never comes to meetings...
[23:30] <cjwatson> psusi: "since no developer can look at it and figure out what he needs to go fix" - where did you get that idea?
[23:30] <cjwatson> I look at New bugs *all the time*
[23:30] <cjwatson> it's far from uncommon for a bug to be New *and* have all the information I need
[23:31] <cjwatson> when I notice, I mark it Triaged, but see above - I get more bug mail than I can process
[23:31] <psusi> cjwatson, sure... and when you see one you should mark it as triaged shouldn't you?
[23:31] <cjwatson> it is the job of a triager to work out what's going on, not to blindly follow the statuses
[23:31] <psusi> right... but if I look at a bug and it amounts to little more than a rant rather than a report of an actuals software defect... it probably shouldnt' remain new
[23:31]  * micahg is scared of how much mail cjwatson gets
[23:32] <cjwatson> would you expect a triage nurse to say "oh, you've been in casualty for eight hours, you can't really be ill, go home"?
[23:32] <ebroder> cjwatson: hmm...i wonder if a part of the problem is that people who are very familiar with particular packages can often understand a bug just by looking at it, when that sort of thing is less accessible to people without that domain knowledge
[23:32] <cjwatson> because that's what's happening
[23:32] <cjwatson> ebroder: almost certainly
[23:32] <cjwatson> psusi: rants with no real content, sure
[23:32] <psusi> cjwatson, I guess I see it in this case as a bit more akin to the patient already died while waiting... send them to the morgue ;)
[23:32] <ebroder> i.e. i'm sure you can look at a grub bug and know exactly what's going on, even if the bug description is *completely* unclear to someone who hasn't had their hands deep in the code
[23:32] <cjwatson> psusi: but they didn't.  I fix four-year-old bugs quite frequently!
[23:32]  * micahg thinks we should have a rule, if you're not familiar, don't touch, ask questions first
[23:32] <cjwatson> this notion that bugs go stale is false
[23:33] <lifeless> +1000
[23:33] <cjwatson> and some of the old bugs are the really interesting ones
[23:33] <micahg> rule number 1 for triage is don't make the patient worse
[23:33] <lifeless> rule number 1 is have your most experienced nurse doing the triage.
[23:34] <micahg> lifeless: that's for the triage manager ;)
[23:34] <psusi> cjwatson, if they are still present in a more current release, but are you really going to fix bugs in grub legacy that work fine in grub2?  I figure the reason you have ignored them for so long is because you had no intention of fixing them because you figured grub2 would take care of it... which it did... so... at best it should be WONTFIX shouldn't it? rather than being ignored as new
[23:34] <cjwatson> psusi: there is at least one significant cluster of grub legacy bugs that I have every intention of fixing
[23:34] <cjwatson> psusi: but you *never asked*
[23:35] <micahg> psusi: he probably hasn't fixed them because $cjwatson_clone = clone $cjwatson doesn't work :)
[23:35] <psusi> yes, if it is old, but properly understood and documented bug, then it should stick around as triaged and maybe get fixed eventually... but when someone reported a problem 4 years ago without enough information to go about fixing it, and they no longer use that system and have moved on to one that does not have the problem so it can not be reproduced... doesn't seem to need to stay new forever
[23:35] <cjwatson> that's not your decision to make
[23:35] <cjwatson> furthermore, Won't Fix is a statement of developer intnt
[23:35] <cjwatson> *intent
[23:35] <psusi> lol.... really?  wow... ok... I got the feeling that you were happy to see grub legacy die
[23:35] <psusi> true
[23:35] <cjwatson> you never asked for the details
[23:36] <cjwatson> if you had, I could have told you, but you just went right ahead
[23:36] <cjwatson> the more people do this, the worse my time problem gets
[23:36] <cjwatson> I know I'm coming off a bit strong here but it's a serious problem for me
[23:37] <cjwatson> at this point, I have to assume that the statuses of bugs in packages I work on are essentially random
[23:37] <cjwatson> I can no longer derive any useful information from them, and thus I have to just look at everything
[23:37] <psusi> ok... so basically I got a little over zealeous and they should have just gone incomplete?  and I should have noticed the ones you had actually touched and talked to you about them first?  understood... of course, if you had marked them as triaged when you understood them and planned on coming back ;)
[23:38] <cjwatson> unless I want to spend about 50% of every day reading bug mail
[23:38] <cjwatson> psusi: I don't accept that this is my fault, for doing *development work* rather than pushing paper
[23:38] <lifeless> psusi: changing a triaged bug to incomplete just adds work
[23:38] <lifeless> psusi: why do that at all ?
[23:38] <psusi> yes yes, I should have been able to tell that if you had touched them they should have just been triaged
[23:39] <psusi> lifeless, because then they can expire when the required information is not provided
[23:39] <lifeless> psusi: sorry, were they set to New? I may have mossed context
[23:39] <cjwatson> psusi: that's just as bad!
[23:39] <psusi> rather than language there for years, often times eventually having other people add useless comments to them about totally unrelated problems
[23:39] <lifeless> psusi: triaged explicitly means that we have all the information needed already.
[23:39] <cjwatson> psusi: languishing for years is better than being closed incorrectly.
[23:39] <psusi> lifeless, right... but they were either new or confirmed... I've been trying to get new bugs to triaged if possible
[23:41] <psusi> cjwatson, why?  if it is just a dumpster for user ranting.. why is it better left new?
[23:43] <cjwatson> psusi: from slangasek's descriptions, that was not the case of some of the bugs you closed, so I don't think you can rely on that justification
[23:43] <cjwatson> psusi: most of the bugs I see people closing incorrectly (or marking Incomplete incorrectly) are *not* just dumpsters for rants
[23:44] <cjwatson> and most of the complaints I see about Launchpad aren't about bugs being full of users' rants, they're about them being full of incorrect triage actions
[23:44] <cjwatson> excuse me, child is crying
[23:55] <kees> neato http://midnightresearch.com/pages/graph-of-running-binary-sections/