=== dendro-afk is now known as dendrobates [00:15] kees: I wonder why he still has a mountall process running [00:16] oh, heck, Ubuntu 9.10 [00:18] yeah, I was going to try to spin that up on a more modern system. === dendrobates is now known as dendro-afk [00:33] cjwatson: re maintainer lock and Ubuntu - Maintainer is Ubuntu developers, so perhaps that means non-developers shouldn't be invalidating bugs? [00:40] sud/win 9 [00:40] pff [00:57] We did get 'won't fix' and 'fix-released' locked now. anything is possible [01:11] charlie-tca: We were rather discussing the opposite problem of people deciding that there was some age that magically made bugs bad. [01:12] yup [01:12] I read the backlogs. That was a comment on the "non-developers shouldn't be invalidating bugs" [01:12] Might help to lock down more statuses === sanchaz is now known as sanchaz-away [01:13] It is hard sometimes to know what to do with bugs, but most developers will tell you if asked. [01:37] psusi: BTW, I'm sorry we didn't meet up at UDS (did you make it? I saw scrollback suggesting you were thinking about going); this conversation would probably have been friendlier over a beer :-) [01:37] indeed, I knew I should have run over there damnit... I didn't realize it was in town until it had started already [01:39] I hopped in the irc channel for a meeting I saw scheduled about grub but nobody seemed to say anything [01:39] I didn't hear about that [01:40] was that a bugsquad meeting? [01:40] I think it was to do with leaving the graphics mode on with the graphics payload option so plymouth could take over the screen without switching back and forth to text mode [01:41] oh, you mean the UDS IRC channel [01:41] most of the conversations were audio-streamed - there was only IRC conversation if people were participating via IRC [01:42] your comment about service ticket vs. bug report resonated with me... it seems like a number of bug reports are really service requests rather than describing a defect.. what is the proper way to handle those? [01:42] anyway, most of that was about organising the kernel bug triage work so that we can actually leave the grub switch on this time round; the bulk of the work has already been done there (although ebroder is doing some extra stuff to let us handle a blacklist/whitelist at boot time) [01:43] that's what I figured... and I was at work at the time so couldn't get the audio streaming [01:43] service requests should often be converted to questions (though ask somebody to double-check if you're going to do that in bulk) [01:44] mostly crash reports should be left where they are, though. it would be nice if we had a separate crash database that was better optimised for that work, but we don't [01:45] cjwatson: we're happy to optimise things in lp [01:45] cjwatson: if you can tell us what you want (or even supply patches ;)) [01:47] well, TBH I think crashes should be entirely separate from bugs, and promotable to bugs once the crash has been analysed [01:48] this seems a tad out of scope for the sort of thing I'm likely to be able to patch in a spare afternoon [01:48] cjwatson: that would make sense to me [01:49] I'm looking at bug #668595 at the moment... I'm sure you can see that the description is not a useful bug report... converting it to a question though eh? I'm not even sure I can frame it as a useful question... [01:49] Launchpad bug 668595 in evince (Ubuntu) "Ubuntu 10.10 Slow as hell after dist-upgrade from ubuntu 10.04" [Undecided,Invalid] https://launchpad.net/bugs/668595 [01:49] not a new idea, though; see https://wiki.ubuntu.com/CrashReporting for instance [01:51] psusi: I agree that that isn't a useful bug, and it would be best to convert it to a question. Doing so doesn't require you to do any framing at all - questions are generally in that kind of phrasing, and the workflow is that helpers work through the problem back and forth with the asker [01:52] (whether anyone will be able to help him, I'm not sure; but the good thing about converting that way is that the message sent to the reporter isn't that their bug has been invalidated, but that it's been moved) [01:52] hrm... ok... [01:52] of course there are certainly other forums, e.g. askubuntu.com seems popular lately [01:54] I mostly only invalidate bugs on the spot when somebody just banged a few random words into the web form, which seems to happen occasionally for installer bugs for some reason [01:57] heh... yea.. saw that one you had touched because ubiquity crashed trying to install grub and the guy said the problem was something about graphics settings... graphics? what?! [01:58] * ajmitch is reluctant to file bugs when it was something along the lines of 'laptop randomly crashed, apport has detected a kernel dump' [01:58] also because apport was taking 3GB of RAM when trying to file it, it never succeeded unfortunately [02:01] sometimes the weirdest things turn out to be relevant though. although it isn't the case right now, you might imagine that grub was looking at the X display resolution at install time in order to construct a splash image, and in that case graphics could well be relevant [02:02] ok... what if a bug does not apply to the current release, but is confirmed and triaged for a previous one? it should be tracked in that release right? but it seems like to get that to happen, you have to nominate it for that release and make a compelling case for an SRU... what if it fails to meet the criteria for an SRU? [02:03] psusi: No, nominating a bug for a release and arguing for an SRU are two different steps [02:03] nomination is a release-manager task [02:03] its going to be locked down soon [02:04] nomination is 'this bug is needed to do that release' [02:04] I thought that was milestone? [02:04] and tracking in a release was to track SRUs? [02:04] I think the proposal was to lock down nominations to developers [02:05] that was what I read at least, and makes a little bit more sense to me than restricting to release managers (since only release managers can *accept* nominations) [02:05] * ajmitch thought that core devs could accept nominations, was that changed? [02:05] right... but don't they only accept a nomination as part of approving an SRU? [02:06] ajmitch: oh, maybe [02:06] psusi: the problem is that the nomination queue is unusable because people see the button and go "ooh, yeah, I'd like that fixed in lucid please" [02:06] exactly [02:06] so it does need to be locked down more than it currently is [02:07] anyway, to answer your question, if the bug is already targeted and fails to meet SRU criteria, then Won't Fix is appropriate, but IMO that action should normally be taken by the body responsible for deciding whether bugs meet SRU criteria, i.e. the ubuntu-sru team [02:07] sure... but is my understanding of the purpose incorrect? isn't it to track an SRU? so if a case can not be made for an SRU, it should not even be nominated? [02:09] hrm... then perhaps a triager should nominate it for the release and note to the sru team that a compelling SRU case can not be made, so it should probably just be set as WONTFIX, but none the less does exist in that release so its status should be tracked there to differentiate it from the development release where it isn't an issue? [02:09] if it doesn't have the faintest hope of meeting SRU criteria, or if developers aren't interested in proposing it, and it isn't already nominated, then the right thing to do is normally to simply set the status according to its status in the development release; that is, if it's fixed there, it should be Fix Released, etc. [02:09] there's no point in shovelling stuff through the nomination queue when we already know the answer is no [02:10] a very large number of bugs exist in stable releases, but we need to be able to do effective stable release management without drowning in them [02:10] effective stable release management includes fixing the right bugs, of course, not just saying no all the time :-) [02:11] so then as a general rule, if a bug is reported in an older release, and they try a new release and find the problem has gone away, it should be marked as fix released rather than targeted to the version where it is known to still be broken? [02:12] ajmitch: motu can accept nominations for universe bugs.. [02:12] maco: ah right, I was probably just asked to accept nominations for things I could upload to :) [02:12] roughly, yes, though I would recommend attempting to understand the problem too. for example I often see people closing bugs for that kind of reason when the problem isn't fixed at all - usually because either the triager didn't have a setup suitable for reproducing the bug in the first place, or because the scope of the problem got more limited [02:13] i believe the lp blog said they were being locked to the bug driver (is that the term?) which in ubuntu's case is Bug Control [02:13] it's normally easy if the reporter says it's gone away; otherwise it's a good idea to make a bit more of an effort [02:13] maco: ah, right, that sounds like what I was misquoting, though [02:13] s/though/thanks/ [02:19] still on this tpoic? [02:19] *topic [02:21] micahg: it's obviously important :) [02:22] indeed [02:24] micahg: I believe it is. Figuring out how to better integrate bug triage efforts and development is an important topic for Ubuntu Development. [02:24] * micahg will review the logs a little later [02:36] I have a wireless card that does not currently work in Ubuntu (any release) "Out of Box." It works by simply running a script, which I uploaded here https://launchpad.net/dell1450usb . How would I make it so that is supported out of box in Ubuntu (hopefully by Natty)? [02:45] Sigh. [02:45] ScottK: ? [02:45] lifeless: ^^^ includes a binary blob, so I don't think it's appropriate for LP. Is there a process for that? [02:46] ajmitch: ^^^ [02:46] ScottK: context? [02:46] lifeless: The branch that gbillings referred to there has a binary blob of some kind in it. [02:46] https://launchpad.net/dell1450usb [02:47] * ScottK didn't think such things were allowed on the public launchpad. [02:47] ScottK: its CC licensed [02:48] * ScottK looks again [02:48] ok what did I miss? [02:48] ScottK: according to the front page that is [02:48] lifeless: doubtful; it looks to me like a binary blob from somewhere upstream (contains a "created 2006" string in it) that's been mislabeled as CC [02:50] grah [02:50] gbillings: do you have redistribution rights for what you've uploaded there? [02:50] gbillings: you didn't upload just a script, you also uploaded a firmware blob - where did this blob come from? [02:50] debian wiki seems to indicate it's non-free firmware from prism54.org [02:52] gbillings: the right way to get such a bug fixed for natty is to file a bug on the linux source package by running 'ubuntu-bug linux'; it's an open question whether we'll be able to use this firmware blob as part of the solution, but when filing the bug please include a pointer to whatever your source for it is [02:55] slangasek: howdy!! By any chance do you have the time to review a couple of library splits (cluster-glue / pacemaker )? [02:56] Okay, so file a bug on the "linux" source package, and include a link to where I got the firmware? right? [02:59] gbillings: I'm disabling the project [02:59] gbillings: because we can't redistribute it [02:59] lifeless, what? [02:59] oh, ok [02:59] so do you wish for me to link to it? [03:00] gbillings: huh? [03:00] i am so confused [03:01] my package is gone [03:01] gbillings: file a bug and explain what you did to get it working on your system. the script that you had in that bzr branch didn't fix the problem in the right place and the right way, so it couldn't be included in ubuntu as it existed there [03:01] yes, it was against the launchpad terms of service because of the firmware blob [03:03] ok I understand both your points. Thanks for saving me the legal trouble! I didnt realize that it was illegal [03:04] I found the firmware here: http://daemonizer.de/prism54/prism54-fw/ ; and wrote the script using information here: http://ubuntuforums.org/showpost.php?p=9304551&postcount=4 [03:05] Are the plenary talks online yet? [03:05] jcastro: ^^^ or will it take weeks like last time? === manusheel is now known as manusheel_afk [03:05] YokoZar: AFAIK they're on blip.tv [03:11] stgraber: found it, "Ubuntu Developers" channel [03:14] filing the bug as I speak [03:18] lifeless: The file is still available through the branch? http://bazaar.launchpad.net/~lymera1n/dell1450usb/trunk/annotate/head:/isl3887usb [03:19] ScottK: yes [03:19] ScottK: https://bugs.launchpad.net/launchpad-code/+bug/669750 [03:19] Launchpad bug 669750 in Launchpad Bazaar Integration "branches for deactivated projects are accessible" [Undecided,New] [03:19] Lovely. [03:20] Thanks. [03:20] filed it earlier when I noticed [03:22] I could have removed it, but it was deactivated [03:24] ScottK, how did u even find that? [03:24] gbillings: I still had the page open from before it was deactivated. [03:25] ScottK, oh, that makes sense [03:26] ok, well sorry for the confusion, and I will be sure not to upload fw blobs again to launchpad. night [05:47] maco: Ubuntu's bug driver isn't bug control, bug control is the bug supervisor [05:47] micahg: there's more than one bug management thingy? [05:48] maco: yes, bug supervisor can set the statuses, bug driver will soon be the ones to accept nominations and bug supervisor will be the one to nominate [05:48] confusing [05:55] micahg: anyone can nominate afaik. [05:55] hyperair: ATM, but that will change soon [05:57] micahg: ah, okay. but what about contributors who want to prepare SRUs? [05:58] hyperair: good question :), we'll have to have them subscribe sponsors or something to do it I guess, I'll bring it up at the bugsquad meeting if the agenda isn;t that long [05:58] you dont need to nominate to prepare an sru... [05:58] maco: it's currently part of the process [05:58] subscribing sponsors is how youd currently get hte debdiff looked at [05:59] and to get the SRU acked, you'd nominate and then subscribe -sru [05:59] no... [05:59] maybe we should chaneg that process a bit. it's kinda weird [05:59] pre-upload ACK is no longer needed [05:59] we can just upload directly to the -proposed pocket. [05:59] yeah [05:59] the sponsor uploads it, and when the sru team sees something in teh queue for a stable release, they go look at hte bug [05:59] hyperair: currently, it's nominate then subscribe sponsors [06:00] as long as you remember to put the LP: # in the changelog, they can find it [06:00] maco: the sponsor should subscribe --sru [06:00] maco: right. so we need to change the process in wiki. [06:00] i wonder how much sru team actually pays attention to subscriptions... [06:00] the rules say they should, sure, but as i understand it it's not actually necessary for the normal sru processing procedure [06:00] iirc it still asked you to nominate or whatever. [06:01] they're subscribed to a MASSIVE number of bug reports [06:01] of /open/ bug reports [06:01] heh [06:01] maco: yes, but they have scripts to help them [06:02] the sponsorship queue doesn't see bugs that are FIX RELEASED and not accepted for a stable release, right? [06:02] ebroder: I would think it should [06:02] * micahg sees SRUs in the queue [06:03] but are those cases where stable release nominations have been accepted? [06:03] ebroder: yes, I think so, I'm starting to see the problem :) === almaisan-away is now known as al-maisan [06:05] hmm...looks like merge proposals stay open. i guess that's another point for udd [06:40] good morning! === hanska is now known as dapal === hunger_ is now known as hunger [08:10] highvoltage, Thanks for the pointer, although I believe the derivation happened the other way in this case, as we had flavours long before Debian had pure blends. [08:13] * Hobbsee flushes the ubuntu-devel ML queue [08:13] there was mail from april there :( [09:32] :( [09:32] ? [09:49] cjwatson: as you TIL gparted last, can you look at bug 669826 (sync for natty) and bug 617885 (maverick SRU candidate) please [09:49] Launchpad bug 669826 in gparted (Ubuntu) "Sync gparted 0.7.0-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/669826 [09:49] Launchpad bug 617885 in gparted (Ubuntu) "gparted crash at start: glibmm-ERROR **" [Undecided,In progress] https://launchpad.net/bugs/617885 === sanchaz-away is now known as sanchaz === sanchaz is now known as sanchaz-away [11:03] who's a good contact for "The Ubuntu Solutions" group within C. ? === sanchaz-away is now known as sanchaz === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [12:27] c [12:27] python [12:34] c#! [12:38] perl === bilalakhtar changed the topic of #ubuntu-devel to: 10.10 released on 10/10/10 at 10:10:10UTC!! | Natty is open | Many SRUs needed for Maverick | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [12:44] Removed the phrase about the UDS channel from the topic [12:59] Good morning [13:09] geser: ok [13:09] * cjwatson adds to growing queue :-( === bilalakhtar_ is now known as bilalakhtar [13:11] Do packages that have passed Debian NEW also need to go through Ubuntu NEW? [13:11] did somebody start doing an autosync run? [13:11] cjwatson, pitti: ^? [13:11] seems the queue has an half done run [13:11] not me [13:12] bilalakhtar: formally yes, but we fast-pace them [13:12] bilalakhtar, somewhat, they go through new but get accepted without checking [13:12] i. e. usually when an archive admin syncs new pakcages from Debian, he would make a list of them and accept them wholesale [13:14] seb128: it's me [13:14] please hold [13:14] not an autosync, I was processing new-source and didn't finish [13:15] cjwatson, ok [13:15] keeps falling over [13:43] seb128: all yours [13:43] cjwatson, thank you! [13:59] pitti: tb meeting shortly [13:59] kees: oh, right; that timezone [14:00] pitti: oh, did it move? [14:01] kees: no, I did :) [14:01] heh, okay. [14:01] kees: but due to the different DST in Europe and US I'm not actually sure whether it's now or in 1 h [14:01] my calendar shows it both times [14:02] yeah. fridge says "3pm", but I don't think it's right === smb` is now known as smb [14:15] Did an aytosync take place recently? [14:15] *autosync [14:16] at least new-source did, from backscroll === RoAk is now known as andreserl [14:28] BlackZ: yes - the package set for ubuntu-server exists [14:28] mathiaz: what packages are part of it? [14:29] BlackZ: edit_acl.py -P ubuntu-server -S natty query using lp:ubuntu-archive-tools === shadeslayer_ is now known as shadeslayer [14:30] Laney: oh, yes, this is a way to know that, thanks! [14:31] or check out http://people.canonical.com/~cjwatson/packagesets [14:32] hmm, that doesn't appear to show all sets [14:32] does have server though [14:33] BlackZ: please before working on any package related to the HA team let me know!! :) [14:33] Laney, I think that shows sets that are related to flavours, and so therefore more interesting for ogre-model, release-tracking, etc. [14:34] RoAkSoAx, Careful: always good to offer support, but we don't have maintainers in Ubuntu, and don't block. [14:34] persia: OK, so I won't bother committing this to memory, and will remember the more general method instead. [14:34] BlackZ: that is all the ha clustering related packages (DRBD, keepalived, RHCS, pacemaker, heartbeat, corosync, cluster-agents, cluster-glue, etc :)) [14:35] persia: That's why I'm saying he should le me know before working on them becuase I care for those packages and we are wroking on them as part of the Cluster Stack Blueprint [14:36] persia: and I might not always want to merge/sync a package sometimes because I have changes to apply and so on... [14:37] RoAkSoAx, I understand, and that's why I'm saying be careful. If you want to maintain stuff in Ubuntu, you have to be quick enough that nobody else has any pending changes without your responses. We frown strongly on anyone who blocks others work, even for packages they tend to upload. [14:38] The one exception is that we discourage random folk from processing merges prior to DIF unless they touched it last *OR* really, really want it because it blocks other work. [14:39] persia: indeed, and again that's why I recommended him to let me know before working on them so that if he does, we can work together :) [14:39] And that's good :) This is why I said "be careful" rather than "we don't do that", because I couldn't quite tell which way you meant it :) [14:39] persia: :) [14:40] persia: language barrier :) [14:40] RoAkSoAx: sure, will do [14:41] roaksoax: a.k.a. IRC as usual :-) [14:41] RoAkSoAx, Yeah, probably. I just want to be careful, as we had some talks around "maintainers" and "ubuntu doesn't have maintainers" at UDS, and consensus appeared to be to push with not having maintainers harder (unless I missed something). [14:43] We are moving towards having smaller teams of people maintain certain packages though [14:44] Laney, Um, sorta, for values of "maintain". We strive to avoid any maintainer block, except in terms of reducing size of groups as we dig deeper in the ogre-model. [14:46] persia: I wonder in what session I was during that talk.. :) And yes I do understand your point and that's how's always been (not having "pkg maintainers"), but in our particular case those packages are undergoing changes that are being worked out with upstream/Debian becuase of the MIR blockers, so we are currently working on them to get them in shape for Main [14:47] Yeah, well, I'm still trying to stuff *every* package in main by fiat without any more MIRs, but it will take another couple cycles. [14:47] Well, not *every* package, but at least all of universe. [14:48] lol :) [14:49] persia: *cough* I think that's more "replace MIRs with some other review process"? [14:49] we've been trying to get the cluster-stack into main the past 2 releases though :) [14:51] cjwatson, No. That said, we *will* need ways to indicate that various packages have undergone security review, code review, etc. I don't think that will have anything to do with the presence/absence in the "main" component. [14:57] persia: I didn't say it would have anything to do with presence/absence in the main component. But saying that MIRs go away is wrong - we need to have some kind of review process [14:58] I suspect that the two of us are agreeing, but I'm trying to make sure other people are not misled [14:58] Oh, certainly. I'm hoping you (and several others) will attend my spec on "package review types and reporting" at next UDS. [14:58] And I think we do agree in general, although the specifics need more discussion. [15:01] feel free to subscribe me so I notice [15:01] persia: me as well, please [15:01] Sure, although it will be another 4-5 months before I write it up. [15:03] cyphermox__: thanks for the super quick review [15:06] ebroder, np. if you have time to apply it to the other branch, then go ahead, otherwise I'll get around to it later ;) [15:06] cyphermox__: i just submitted a new merge proposal. i'm not in any rush; just wanted this done by release :) [15:07] ebroder, alright, thanks! [15:19] hi folks, now that pysupport for python 2.7 has landed for natty, i need to get the python-cheetah package rebuilt. 2.4.3-0ubuntu1 is published but ftbfs because pysupport was out of date. now that the latter is fixed, i think we just need a rebuild but i don't seem to be able to (or maybe know how) to request that from launchpad. does an archive admin need to do that? [15:20] barry: no, any uploader [15:20] we don't have binary-only rebuilds in LP yet, so you have to bump the changelog and reupload [15:20] oh, wait [15:20] did it build to start wth? [15:21] cheetah | 2.4.3-0ubuntu1 | natty | source [15:21] python-cheetah | 2.0.1-2ubuntu7 | natty | amd64, armel, i386, powerpc [15:21] cjwatson: we sync'd 2.4.3 from debian but that build failed [15:21] looks like not [15:21] $ ubuntu-build --batch --retry cheetah [15:21] done [15:21] cjwatson: it should build now that pysupport is updated (it builds in my chroot just fine now) [15:22] cjwatson: awesome, thanks! [15:22] the script's in ubuntu-dev-tools and anyone with upload access can use that. alternatively it's in the web UI for each build page, though that takes longer [15:23] cjwatson: yep, that's why i can see the ui widget for my ppas but not (yet ) for the cheetah page [15:24] The conventional way for non-uploaders to request rebuilds for which no binaries exist is "Could someone please give-back foo on arch bar?", which almost always results in someone pressing the button within 10-15 minutes for me. [15:27] persia: "give-back"? [15:27] barry, Yeah. Historical terminology from the Debian wanna-build infrastructure. [15:27] barry: give back to the buildd [15:27] ah, thanks [15:28] * barry thought it was something like "pay it forward" :) [15:28] we really should have a glossary of debian terms somewhere [15:31] tumbleweed: dholbach is working on that i think! [15:32] errrrrrrrrrrr [15:32] guys, I don't own the wiki :-P [15:32] for now, there's https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/glossary?action=show&redirect=UbuntuDevelopment/Abbreviations :) === zyga is now known as zyga-afk === dholbach_ is now known as dholbach [15:34] barry, tumbleweed: for now, there's https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/glossary?action=show&redirect=UbuntuDevelopment/Abbreviations :) [15:34] it should be linked form UbuntuDevelopment/KnowledgeBases afaik [15:34] but yeah, there should be some better "introductory docs" at the end of this cycle [15:34] dholbach: i was thinking about your documentation ideas at uds-n, specifically the idea (maybe only in my own head) about a reference manual and glossary [15:36] the one I had in mind doesn't have the spec written yet, but it was the one about having introductory test/ presentation /etc. that in a way that's easy to understand at least mentions all the big topics and explain how they fit together plus a few nice diagrams [15:36] it's not going to replace a glossary [15:36] * barry nods [15:37] but we should make sure to get a few nice articles together for the other spec - I hope that'll make it easier to bring all the buzzwords in context :) === beuno is now known as beuno-lunch === KIAaze_ is now known as KIAaze === al-maisan is now known as almaisan-away === zyga-afk is now known as zyga === jono__ is now known as jono [16:32] so, is there a reason some packages have Vcs-Bzr: renamed to Xs-Debian-Vcs-Bzr: ? is that an anachronism that can be removed? [16:33] SpamapS: Vcs-Bzr: is canonical according to http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs [16:33] SpamapS: Does this package have another Vcs-Bzr in place? There's sometimes Ubuntu branches. [16:34] SpamapS: When I've done it, it's been intentional. [16:34] it would be nice if this were standardised so that tools can make use of it [16:34] SpamapS: If a package isn't synced directly from Debian, claiming that its packaging is kept in the same vcs as Debian is a lie. [16:35] SpamapS: So I change it to Xs-Debian-Vcs-Bzr. [16:35] SpamapS: And put a new Vcs-Bzr header there if there's a better, Ubuntu-specific place for the packaging branch. === sanchaz-away is now known as sanchaz [16:39] The package is merged from Debian [16:40] the package in question is cheetah btw [16:40] and the weird thing there is, basically all Ubuntu packages have a place where their uploaded versions live. Its only the WIP versions that are missing.. and according to somebody at UDS (forgetting who now) that can be resolved. [16:50] pitti: howdy, when using pmutils, pm-powersave is there a tool that will list which scripts are enabled/disabled? No right? === sanchaz is now known as sanchaz-away [16:51] pitti: I seem to recall a discussion at a previous UDS where we talked about executable bit on windows files when mounting a cdrom...did that ever get done? Is bug 561479 the only one for that? [16:51] Launchpad bug 561479 in udisks (Ubuntu Maverick) "Windows executable on unwritable removable media cannot execute with Wine due to lack of executable bit" [High,Triaged] https://launchpad.net/bugs/561479 === sanchaz-away is now known as sanchaz === sanchaz is now known as asdasdsadasd [16:52] mdeslaur, https://launchpad.net/ubuntu/maverick/+source/udisks/1.0.1-2 === asdasdsadasd is now known as sanchaz [16:52] we had this patch last cycle [16:53] but I guess it's a different issue now reading your bug [16:53] seb128: oh, curious...it doesn't work for me [16:53] seb128: oh, well, cdroms aren't vfat [16:53] seb128: so it wouldn't be that patch [16:54] right === yofel_ is now known as yofel [17:10] RoAkSoAx: how do you mean? They are all enabled [17:11] mdeslaur: exe bit? that got fixed for vfat [17:12] mdeslaur: not sure what happens with iso9660 these days [17:12] pitti: yes, but unfortunately not for iso9660 cdroms [17:12] pitti: for example, when we were discussing powernap scripts before UDS with kirkland, we decided that we needed to know which power saving scripts are enabled and which are disabled. So I created a tool to enable/disable and list all the scripts with its status. Now, I'd like to keep that functionality [17:12] pitti: so people using wine can't install windows programs from cdrom [17:13] pitti: however, since we are now gonna use pm-powersave for such purpose, I was just wondering :) [17:13] RoAkSoAx: in /etc/ you can rename the files [17:13] pitti: on lucid and maverick, if the cdrom device is listed in fstab, it gets mounted with the executable bit everywhere. If it's not listed in fstab, it gets mounted with read permissions only. [17:13] RoAkSoAx: but /usr/lib/pm-utils/power.d/ will always run (unless these scripts have a way to disable themselves by reading a file in /etc) [17:14] mdeslaur: maybe we need a showexec option for iso9660 that only takes effect if the cd doesn't use rock ridge? [17:15] mdeslaur: I see; seems iso9660 doesn't have a "showexec" equivalent :( [17:15] ebroder: yeah, I think that would be the best approach [17:15] * pitti agrees [17:15] pitti: yeah jsut saw the manpage. I guess that the best thing to do in this case would be to adapt the tool I wrote to work with those two directories. [17:16] * pitti lunch & [17:16] kees: hey [17:16] kees: so, was the token based thing faster ? [17:17] lifeless: since I can't reproduce the 503s with bug attachments, I won't know until I can test against soyuz output [17:17] kees: ah, its just big files right... [17:17] I think it will be :) [17:18] lifeless: I have faith :) === ivoks is now known as ivoks-afk === zyga is now known as zyga-gone === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [17:55] pitti: I just uploaded a new apparmor to maverick-proposed to fix that ftbfs and a missed patch. please see bug #660077 [17:55] Launchpad bug 660077 in apparmor (Ubuntu Lucid) "update AppArmor to 2.5.1 (for upstream and backported maverick kernels)" [High,In progress] https://launchpad.net/bugs/660077 [17:55] pitti: I am going through the lucid one next to answer all your questions, etc [17:56] kees: thanks for quick MIR review, appreciated [17:56] pitti: np [17:57] pitti: I took the liberty of rejecting the lucid one, since it will need the same changes as the one I just uploaded to maverick [17:57] jdstrand: thanks for the heads-up [17:58] pitti: for clarity, I did not accept the maverick-proposed one, since I uploaded it [18:04] Has anyone attempted to make mk-sbuild use btrfs instead of lvm snapshotting? What better way is there to get heavy testing of btrfs than start doing all of our local test builds on btrfs? [18:04] SpamapS: has sbuild grown btrfs support yet? last time i checked i thought it didn't have it yet [18:04] (it already uses aufs by default now) [18:09] well I guess I meant sbuild. ;) [18:09] err, actually, i think i mean schroot, not sbuild, but you know... [18:10] * ebroder goes and looks around [18:11] aha. yeah, (experimental) btrfs support has been in schroot since 1.4.5-1. so mk-sbuild just needs to be changed to set the appropriate options in schroot.conf === cyphermox__ is now known as cyphermox [18:23] ebroder: cool [18:23] * SpamapS adds a personal todo to try that out === manusheel_afk is now known as manusheel [18:45] hallyn: okay, so qemu-kvm-0.13 built and is in natty; any others waiting on sponsoring by me? fwiw, I usually do [qemu-kvm, vgabios, seabios, etherboot] all at roughly the same time [18:46] hallyn: and will help jdstrand with [libvirt] if necessary [18:47] kirkland: i think jdstrand is ready for me to just take over libvirt :) [18:47] kirkland: etherboot doesn't need an update. you already did seabios i believe, and i'm not sure about vgabios (or vice versa on the last two) [18:47] I don't mind doing the apparmor bits, but it is difficult for me to maintain all the other bits [18:47] hallyn: heh :-) [18:47] hallyn: cool [18:48] jdstrand: np, i'll do it as of natty? [18:48] jdstrand: shall i put you down as reviewer for merge request? [18:48] hallyn: well, for all of the bios packages [seabios, vgabios, etherboot], i only merge to fix bugs and stay in sync with qemu; they are not exactly "feature driven" projects at this point [18:48] hallyn: that sounds excellent (if slightly surprising based on our last conversation) [18:48] hallyn: so there's nothing wrong with holding steady there [18:48] hallyn: yes please [18:49] slangasek: Just FYI if I don't get multiarch by 11.04 I'm gonna add all the gstreamer codecs and their dependencies to ia32-libs [18:49] jdstrand: cool, then let's do that [18:49] \o/ [18:49] hallyn: as for libvirt, I just try to make sure that we have roughly the same libvirt/qemu-kvm combination as Fedora, if possible; tends to minimize the maintenance [18:50] kirkland: uh, ... so i shouldn't just take the lastest (0.8.5) release for natty you think? [18:52] hallyn: my vote is for 0.8.5 as early as possible, that way there won't be any surprises later in the release (especially since Debian is trying to get squeeze released) [18:52] hallyn: well, yeah, it's probably good at this point to just take that as soon as possible [18:52] hallyn: right, what jdstrand said [18:52] ok [18:53] hallyn: as it gets closer to FF and Beta, that's when, if possible, I try to make sure that we have something close to what Fedora has [18:53] makes sense [18:54] hallyn: and hopefull we'll get a few good qemu-kvm 0.13.x updates in the next 4-5 months too [18:54] hallyn: those have been *really* good for the project, IMHO [18:55] kirkland: well i guess i'll need to update a laptop to natty so i can actually test it [18:55] suppose to do that i just tweak sources.list and do it by hand? [18:55] (and pray) [18:56] hallyn: or do-release-upgrade -d [18:59] kirkland: not in THIS laptop tyvm :) [18:59] kirkland: thanks, i didn't think that would work yet, will do [19:00] * stgraber upgraded his x201s yesterday. It actually seems to work better since then ;) [19:00] hm, maybe nouveau will be more stable :) [19:00] 2.6.36 helped for a few stuff [19:01] like I can get X applications working in a LXC container as containers can now access unix sockets if the container has access to the file system [19:04] stgraber: hm, i can't think what kernel patch that would have ben [19:06] hallyn: http://marc.info/?l=linux-netdev&m=127132268217222&w=2 ? [19:06] hallyn: not sure that's the one but it seems to match the description dlezcano gave me at uds [19:07] Wierd, package liboauth has cleared the Ubuntu NEW queue by the autosyncer but another copy of it is still in the queue! [19:08] stgraber: oh, cool. more corner cases [19:08] Can someone delete the queue copy? I uploaded it myself a few hours ago, didnt know the autosyncer would run today itself [19:29] bilalakhtar: which queue copy? natty isn't frozen [19:29] unless it was a pakcage in main? [19:29] pitti: NEW queue [19:29] sorry, s/main/new/ [19:31] bilalakhtar: why would I remove the binaries? I should accept them.. [19:31] oh, sourc [19:31] pitti: I mean the source [19:31] done [19:31] thanks pitti [19:33] f === zyga-gone is now known as zyga === ivoks-afk is now known as ivoks [20:18] cjwatson: re gparted: should I ask someone else for sponsoring both bugs? (both bugs are also in the sponsoring queue) [21:02] jdstrand: hey, now i can't recall what soren (was it soren?) was admonishing you for - does he want the quitl patches APPLIED or NOT APPLIED in the bzr tree? [21:02] both are accepted models: check the status of other patches in the package. [21:02] hallyn: 09:11 < soren> jdstrand: The quilt source packages are special. When I add a patch, I need to add it both to debian/patches /and/ apply it to the source tree. [21:03] hallyn: ie, 'quilt push -a ; bzr add' before committing [21:03] thanks [21:04] dpkg-buildpackage usually applies them for you if you build the source [21:04] jdstrand: one more q - do you have a process all figured out for how you set up the gnulib/ directory? [21:04] or do you do it ad-hoc? [21:06] hallyn: I would hope that upstream already did that in their upstream tarball. did they not? [21:06] oh. i was going to take from git :) [21:06] 0.8.5 is released. I recommend that [21:06] yes, [21:07] i was doing 'git reset --hard' to that commit-id :) [21:07] so you do a 'uscan' and then copy that back into the bzr tree? [21:08] hallyn: well, I haven't done a source merge since soren requested we use this method [21:09] hallyn: there are prbably better ways to do it, but I personally would delete everything out of the directory except .bzr*, then untar into it. then 'bzr add' [21:09] all right, will do. [21:09]