[00:01] <kees> okay, ubuntu2 uploaded, and I've added a note to the bug.
[00:04] <kirkland> kees: thanks for uploading
[00:16] <MTecknology> I'm so happy I caught that sudo bug being mentioned in here :P
[00:37] <rickspencer3> kirkland, did you figure out your status.net thing?
[00:37] <rickspencer3> I think it's robbiew, btw
[00:41] <lool> crimsun: pulseaudio works across resumes on Ubuntu, yes
[00:50] <mwhudson> someone please explain pinning to me :-)
[00:50] <mwhudson> i'm writing this software that assembles debs from a bunch of archives
[00:50] <mwhudson> (it fetches them using python-apt)
[00:50] <mwhudson> i want it to very much prefer one archive, even if another archive has a later version
[00:51] <mwhudson> i have a feeling this involves editing /etc/apt/preferences (in the kinda fake chroot the code uses)
[00:52] <RAOF> I believe ‘apt pinning’ is the search term you're after; I need to look it up every time I try to touch it, so I'm not going to say anything more than that :)
[00:52] <mwhudson> yeah
[00:52] <mwhudson> it's what goes on the Pin: line that's a bit confusing to me
[00:53] <Pici> !pinning
[00:53] <Pici> Thats all I know about it too ;)
[00:53] <kees> mwhudson: it's what to pin, so like:  Pin: release a=$RELEASE
[00:53] <kees> where $RELEASE is natty, maverick, etc
[00:54] <mwhudson> ah hah, the end of http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html seems to be what i want
[00:54] <mwhudson> $RELESE comes from where? a Release file in the archive?
[00:54] <kees> it's just a name, so   Pin: release a=natty
[00:54] <kees> I've only ever using pinning for this crazy script: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/annotate/head%3A/utilities/downgrade-all
[00:55] <kees> that'll remove everything not in the primary archives.
[00:57] <mwhudson> hm, looks like i'll need to make a Release file then
[00:57] <mwhudson> (the archive i want to prefer is created from scratch)
[00:57] <kees> mwhudson: I think you can put other thing on the Pin line, I've just never used any others
[00:57] <mwhudson> kees: they all seem to come from the Release file
[00:58] <kees> in that case, see this tool http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/annotate/head%3A/repo-tools/update_repo
[00:58] <ebroder> For what it's worth, there is an apt_preferences(5), but I've never found it to be that useful
[00:58] <ebroder> apt-cache policy <package> is also useful for seeing how your pinning rules interact
[00:58] <mwhudson> well, according to this documentation from 2005
[01:03] <mwhudson> hmm
[01:03] <mwhudson> about ubuntu on my maverick system seems to think i'm running natty....
[01:06] <mwhudson> oh https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/690248
[01:10] <kees> hah, whoops
[01:55] <hyperair> how do i get apport to unignore crashes?
[01:57] <ScottK> export CRASHALLTHETIME=True
[01:59] <hyperair> ScottK: er where?
[01:59] <ScottK> hyperair: Sorry.  Bad joke.
[01:59] <hyperair> oh
[01:59] <hyperair> haha
[02:00] <hyperair> i'm beginning to really hate glib's memory management
[02:00] <ScottK> hyperair: How about "sudo service apport start force_start=1"
[02:00] <hyperair> ScottK: no, that's different.
[02:00] <hyperair> ScottK: i clicked that checkbox "ignore future crashes for this version"
[02:00] <hyperair> it's not like i completely disabled apport
[02:01] <ScottK> hyperair: OK.  Is it in /etc/apport/blacklist.d/apport?
[02:02] <ScottK> Or that vicinity ...
[02:02] <hyperair> ScottK: nah, it's not there =\
[02:02] <hyperair> i'm trying to debug this dbusmenu crasher i just created by mistake
[02:02] <hyperair> did you know glib's memory management sucks?
[02:02] <hyperair> really really hard?
[02:03] <hyperair> i'm actually amazed at how little people are complaining about dbusmenu and indicator memory leaks
[02:03] <hyperair> because if dbusmenu is leaking, pretty much every indicator-using application is leaking
[02:06] <ScottK> Much of the target audience for Ubuntu desktop is used to the idea that having to reboot to fix a computer is normal.
[02:08] <hyperair> heh
[02:08] <hyperair> i mean even among devels.
[02:09] <ScottK> Dunno.  You're using a different dbusmenu implementation than I am.
[02:13] <hyperair> ScottK: KDE uses a different one?
[02:43] <ScottK> Sure.  It's a standard part of KDE.
[02:55] <ebroder> hyperair: My guess for that would be /var/lib/apport or the like, but I don't actually know
[03:02] <hyperair> ebroder: hmm it's not there either
[03:06] <ebroder> hyperair: How about ~/.config/apport?
[03:20] <hyperair> ebroder: doesn't exist
[03:20] <ebroder> Ok, I give up
[03:21] <hyperair> haha
[03:21] <hyperair> nevermind, i've figured out where it was crashing
[03:21]  * hyperair forgot to g_value_init before g_value_copy
[03:57] <crimsun> lool: thanks, will see about pushing it into git.
[06:55] <dholbach> good morning!
[07:08] <dholbach> what's the magic runes in grub so I can boot natty with nvidia drivers? is that gfxpayloadsomethinsomething? :)
[07:09] <ebroder> dholbach: edit /etc/default/grub, uncomment the GRUB_GFXPAYLOAD_LINUX line and set it to text
[07:09] <dholbach> aha! thanks a lot ebroder
[07:09] <ebroder> Then run update-grub
[07:09] <dholbach> sweet
[07:09] <dholbach> I'll try that
[07:11] <dholbach> ebroder, I don't have that line - I guess I just add it and set to text, right?
[07:12] <ebroder> dholbach: Yeah
[07:12] <dholbach> alright, let's see what happens :)
[07:13]  * dholbach hugs ebroder
[07:13] <dholbach> thanks
[07:13] <ebroder> No problem
[08:08] <cjwatson> dholbach: you've filed a kernel bug, right?
[08:08] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032244.html
[08:09] <dholbach> cjwatson, will do when I get back to the machine
[08:11] <ebroder> cjwatson: For what it's worth it's starting to sound like nvidia-current can't handle this across the board
[08:12] <ebroder> cjwatson: Oh wait, I take that back. I had heard of it working in one case
[08:14] <cjwatson> ebroder: I've definitely had at least one positive report from a user of nvidia-current
[08:15] <cjwatson> and of course I guess it differs between nouveau and nvidia so we'll need to figure out how to handle that
[08:16] <ebroder> cjwatson: Yeah, I've been trying to come up with something for that that doesn't involve putting the blacklists in the nvidia-* and fglrx packages
[08:16] <ebroder> And for what it's worth, I haven't forgotten that I owe you a C module
[08:18] <cjwatson> heh
[08:18] <cjwatson> ebroder: we could have a .d directory for the blacklists </ugh>
[08:19] <ebroder> cjwatson: Sure, it would be a lot nicer if the blacklist files were all kept in one package separate from either grub or the driver packages
[08:21] <cjwatson> ebroder: I dunno, I was thinking about that and wondering if it was overengineering to keep it separate from grub2
[08:22] <cjwatson> it would mean we'll have to have breaks each way when the format changes, etc. ...
[08:22] <cjwatson> but it does mean we don't have to change the bootloader to change the blacklist.  meh
[08:23] <ebroder> cjwatson: Yeah, but I suspect we're going to want to rev this increasingly frequently as we get closer to release
[08:24] <cjwatson> there is one tricky bit though
[08:24] <cjwatson> it's in $prefix, which means it really ought to be dealt with by grub-install
[08:24] <cjwatson> that means (say) grub-gfxblacklist would have to deal with running grub-install on upgrade
[08:24] <cjwatson> that's a REALLY hairy bit of code
[08:25] <cjwatson> see grub-pc.postinst for the horror
[08:25] <cjwatson> I'd kind of prefer to keep the invariant that only grub-$platform runs grub-install
[08:25] <ebroder> That thought had crossed my mind. Unless I'm forgetting what I wrote, I intentionally didn't name the file foo.lst to avoid the grub-install wiping it out, so we can have update-grub drop it into place
[08:25] <cjwatson> you named it gfxblacklist.lst, actually :)
[08:25] <ebroder> Ah, curses
[08:26] <cjwatson> grub-install doesn't remove foreign .lst files though
[08:26] <ebroder> I'm pretty sure it has a rm $prefix/*.{lst,mod,a few others}
[08:26] <cjwatson> I don't see that
[08:26] <cjwatson> oh, wait, you're right
[08:27] <ebroder> It's a bit obtuse. But it's focused enough that we can name our files around it
[08:27] <cjwatson> however: we could have grub-gfxblacklist install it in /usr/lib/grub/i386-pc/ so that grub-install will copy it, and additionally refresh it at update-grub time
[08:27] <cjwatson> that seems reasonable if slightly twisty to me
[08:28] <ebroder> refresh it> as in refresh the one in $prefix?
[08:28] <cjwatson> or actually not even update-grub, just refresh it in grub-gfxblacklist.postinst
[08:28] <cjwatson> yeah
[08:28] <ebroder> Yeah, that doesn't seem too horrid
[08:28] <cjwatson> saves having to write a grub.d hook with no output or whatever
[08:44] <dholbach> smoser, you're still listed in the topic as patch pilot :)
[08:44] <dholbach> (I guess you need to change nick to smoser` and "@pilot out" again)
[08:44] <seb128> dholbach, hey
[08:45] <dholbach> hey seb128 - good work yesterday!
[08:45] <seb128> dholbach, thanks!
[08:45] <dholbach> down to 30!
[08:45] <seb128> ;-)
[08:45] <dholbach> we're getting there :)
[08:45] <seb128> in fact less
[08:45] <seb128> we should filter out the incomplete
[08:46] <seb128> or the merge requests that are "need fixing"
[08:46] <seb128> half of the list are things that need work
[08:46] <dholbach> hmhmhm
[08:46] <seb128> see the status column
[08:46] <ebroder> One problem I've noticed is that UDD branches are by default reviewed by ~ubuntu-branches, so nobody can get them out of the queue
[08:46] <seb128> (Needs fixing)
[08:46] <seb128> (Needs fixing)
[08:46] <seb128> etc
[08:47] <seb128> ebroder, right
[08:47] <ebroder> Some people set them to ~ubuntu-sponsors or ~ubuntu-dev, which is great, but most don't
[08:48] <dholbach> ebroder, that's no problem - the script that generates http://reqorts.qa.ubuntu.com/reports/sponsoring/ takes care of that
[08:49] <seb128> there is also some "Disapprove" in the list
[08:49] <dholbach> seb128, aha!
[08:49] <ebroder> dholbach: Look at http://bit.ly/fFlmak for instance. I wanted to reject that and take it out of the queue, but I couldn't
[08:49] <seb128> the logilab one for example
[08:49] <dholbach> seb128, we should set the status of the merge proposal to "work in progress" then
[08:49] <seb128> dholbach, why?
[08:49] <seb128> the correct status is "Needs work"
[08:49] <dholbach> because work is required?
[08:49] <seb128> work in progress would suggest someone is doing the work
[08:49] <dholbach> seb128, not comment status, but merge proposal status
[08:49] <seb128> right
[08:50] <dholbach> right now I only check for "Needs Review" because LP can give me that easily
[08:50] <seb128> but I take "Work in progress"  as "is being worked"
[08:50] <dholbach> well
[08:50] <dholbach> there's only "WIP", "merged", "needs review"
[08:50] <ebroder> dholbach: What about removing a MP from the sponsor queue if there's a negative review from someone on ~ubuntu-dev? (Assuming you can look at just comments starting from the last time the MP was resubmitted)
[08:50] <seb128> dholbach, no there is not
[08:51] <seb128> there is "Needs Work"
[08:51] <seb128> but the status is not available for some reason
[08:51] <dholbach> seb128, I'm talking about the status right at the start of the page
[08:51] <ebroder> seb128: It's at the very top of the page
[08:51] <dholbach> that's what I call "merge proposal status"
[08:51] <repete> persia, What is the default browser for Ubuntu on ARM?
[08:52] <seb128> dholbach, right sorry, I'm being confused
[08:52] <dholbach> ebroder, the problem is that subsequent reviews (maybe in a resubmitted proposal) might approve it again - it's a bit tricky
[08:52] <seb128> that's "rejected" which is missing
[08:52] <seb128> on https://code.launchpad.net/~dobey/ubuntu/natty/logilab-common/namespace-packages/+merge/43841 for example
[08:53] <seb128> dholbach, I'm fine using wip to filter things out if you want
[08:53] <seb128> we should just make clear it's the way to do it
[08:53] <ebroder> dholbach: It might be useful to send mail to u-d or something so that people know that in general
[08:54] <apw> @pilot in
[08:54] <dholbach> if you think there's a better way (like find a way to parse if one of the last comments disapproves/needs-fixing, etc.), you could file a bug on https://launchpad.net/ubuntu-sponsoring/+filebug
[08:55] <dholbach> or if we think that "Needs information" in terms of sponsoring bugs should be filtered out too, we can discuss that in the bug
[08:55] <dholbach> (if that's intuitive enough)
[08:55] <ebroder> No, I agree - I can't come up with a scheme that doesn't break down with multiple valid reviews
[08:56] <seb128> dholbach, what about filtering out "Incomplete"?
[08:56] <seb128> does that requires discussion?
[08:56] <ebroder> seb128: Uh, I think the queue might need better detection of what the relevant bugtask is before we start doing that
[08:57] <dholbach> ugh, yeah, ebroder's right
[08:57] <ebroder> (It frequently picks the wrong one right now)
[08:57] <dholbach> we should stop using bugs with patches altogether :)
[08:57] <seb128> ok, so we should unsubscribe the sponsor and ask to subscribe them again when the issue are adressed?
[08:57] <dholbach> but if it's just one ubuntu task it should be easy
[08:58] <dholbach> I'll file a bug about that one
[08:58] <ebroder> seb128: Yes, for bugs definitely unsub sponsors if you ask them to fix something, and tell them to resub when they're done
[08:58] <ebroder> dholbach: LP doesn't always get the right bug component for linked branches, either :-P
[08:58] <dholbach> and for the merge proposals we could do something like define a bunch of bad_statuses (disapprove, needs work, needs info, etc.) and see if those are the last comments that were added
[08:59] <dholbach> ebroder, then we can drop the code for bugs and just do merge proposals ;-)
[08:59] <ebroder> dholbach: Check out the bugtask LP chose for https://code.launchpad.net/~broder/ubuntu/lucid/update-inetd/fix-601732/+merge/40737, though
[08:59] <seb128> one other issues is that some merge proposed are not listed
[09:00] <seb128> but I'm not sure how to fix that
[09:00] <dholbach> seb128, which one?
[09:00] <seb128> like desktop ones
[09:00] <seb128> because we don'tuse lp:ubuntu
[09:00] <seb128> but a team vcs
[09:00] <seb128> so the mp are for the ubuntu archive
[09:00] <seb128> but it's not trivial to make the difference between those and a random vcs merge proposal
[09:00] <seb128> I guess that's what we get for using a team vcs :p
[09:01] <dholbach> yeah, shame on you
[09:01] <dholbach> bug 690998
[09:02] <seb128> we would need a way to say "if the merge proposal is against the official vcs"
[09:03] <dholbach> bug 691000
[09:03] <dholbach> that's at least bug reports - I can't promise I'll get to it soon :)
[09:03] <ebroder> dholbach: Looks good. Thanks
[09:04] <repete> davidm, you still working?
[09:04] <repete> davidm, or just not signed out?
[09:09] <seb128> dholbach, so set the status to wip would filter things out already?
[09:09] <seb128> or is that something that need to be added to the code?
[09:09] <dholbach> seb128, no, it should do the trick
[09:11] <seb128> dholbach, thanks
[09:12] <dholbach> seb128, de rien mon ami
[09:29] <tkamppeter> I want to overtake a package from Debian without any Ubuntu changes, how do I do a new package introduction and sync at the same time? It is http://packages.debian.org/source/sid/pyppd.
[09:31] <seb128> tkamppeter, new sources are regularly synced from debian
[09:34] <tkamppeter> seb128, how long will that take? Some weeks ago the pyppd package was added to Debian unstable and now I need it to be able to build foomatic-db in sync with Debian.
[09:46] <tkamppeter> pitti, hi
[09:46] <seb128> tkamppeter, he's on holidays until end of year
[09:47] <seb128> tkamppeter, not sure about syncs, cjwatson used to do those almost daily
[09:47] <bdrung> kees: thanks for taking care of the sudo issue
[09:47] <tkamppeter> seb128, thanks.
[09:47] <tkamppeter> cjwatson, hi
[09:47] <seb128> tkamppeter, you can open a sync request bug if you are blocked on it
[09:49] <seb128> tkamppeter, I can sync that one for you now
[09:49] <AnAnt> would someone sponsor this merge: LP #691009 ?
[09:50] <seb128> AnAnt, you can try pinging the current patch pilot, see topic
[09:50] <AnAnt> apw: ping ^
[09:50] <AnAnt> smoser: ping ^
[09:51] <AnAnt> seb128: thanks
[09:51] <seb128> you're welcome
[09:51] <apw> AnAnt, hiya
[09:52] <AnAnt> apw: would you sponsor this merge: LP #691009 ?
[09:52] <apw> AnAnt, i will look it over in a sec ... thanks for the pointer
[09:52] <AnAnt> apw: thanks
[09:56] <AnAnt> be back in few mins
[10:03] <tkamppeter> seb128, would be great if you could sync pyppd for me. I do not find any instructions for importing from Debian or for sync requests in the Wiki.
[10:04] <seb128> tkamppeter, https://wiki.ubuntu.com/SyncRequestProcess
[10:22] <AnAnt> back
[10:33] <tkamppeter> seb128, thanks for the link. When the package is not yet in Ubuntu, to which package assign the sync request? Or can you simply sync pyppd for me?
[10:33] <seb128> tkamppeter, in those case assign to no package
[10:34] <seb128> I can but I would like to check with cjwatson if he's going to do a new-source run before
[10:34] <tkamppeter> seb128, OK, thanks.
[10:54] <cdbs> BlackZ: Just saw your mail, so this means that we should avoid upgrading to *ubuntu1 of sudo?
[10:58] <BlackZ> cdbs: there's another version with the workaround, so yeah. But I think you will upgrade to the version with the workaround instead as it's in the archive now
[11:05] <sebner> BlackZ: ehm, how should I apply the workaround as I can't open the file with root rights? ¬_¬
[11:08] <BlackZ> sebner: you might try with a live CD?
[11:08] <sebner> BlackZ: well, I guessed so far. No easier solution?
[11:09] <DrKranz> sebner: try passing single to grub
[11:09] <sebner> DrKranz: \o/
[11:09] <DrKranz> don't know whether it works or not, though
[11:10] <DrKranz> sebner: if everything fails, format C:\^W^Wreinstall :)
[11:10] <sebner> DrKranz: pfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff :P
[11:12] <BlackZ> sebner: or with rescue mode or something like that (if you have that available)
[11:12]  * sebner reboots and sees if the magic happens
[11:17]  * sebner hugs DrKranz 
[11:17] <DrKranz> worked?
[11:19] <sebner> DrKranz: yeah
[11:19] <DrKranz> nice
[11:20] <DrKranz> maybe adding that as a workaround could help
[11:56] <cjwatson> tkamppeter: I'll sort it out
[11:56] <cjwatson> sebner: ^-
[11:56] <cjwatson> oops
[11:56] <cjwatson> seb128: ^-
[11:57] <sebner> np
[11:58] <cjwatson> tkamppeter: if by "some weeks ago" you mean "ten days", I suppose ...
[11:58] <cjwatson> but yeah, I seem to have been slacking there ...
[11:58] <seb128> cjwatson, thanks
[12:02] <udienz> seb128: i choose to merge into natty
[12:02] <udienz> seb128: but source branch already updated
[12:02] <BlackZ> cjwatson: could you approve my e-mail sent to ubuntu-devel-announce@l.u.c ?
[12:03] <udienz> seb128: i use bzr merge-package but last commit from lp:ubuntu/checkbox doesn't appear
[12:04] <cjwatson> BlackZ: done.  Does user-setup need to change to put that bit somewhere else in future?
[12:11] <BlackZ> cjwatson: thanks. I did some tests and I noted that. Is there a separate part for that on ubiquity?
[12:11] <cjwatson> no.
[12:19] <BlackZ> cjwatson: ok, then I'd say yes; AFAIK that's done by user-setup-apply
[12:20] <cjwatson> BlackZ: please file a bug / add a bug task
[12:20] <cjwatson> I can take care of the details, I just need to know where the configuration should go
[12:21] <cjwatson> and I want a record of it in a bug so that I have it later
[12:22] <BlackZ> cjwatson: I will add a bug task ASAP
[12:22] <BlackZ> cjwatson: should I subscribe you to the bug report?
[12:39] <apw> @pilot out
[12:55] <cjwatson> BlackZ: no need
[12:55] <cjwatson> thanks
[13:08] <cjwatson> tkamppeter: sorted now, binaries will be available after the next full publisher run (so a bit over 1.5 hours)
[13:31] <ScottK> Does anyone know if pitti is expected to be around today?
[13:36] <seb128> ScottK, he's away until the end of the year
[13:36] <seb128> he might still read emails though he said to drop him an email if required
[13:36] <ScottK> seb128: Thanks.  Do you know who's taking his place on SRU approvals?
[13:37] <seb128> I don't think there is anything formal
[13:37] <seb128> he did SRUs yesterday and he's not the only one in the team
[13:37] <seb128> you can probably ping someone from ~ubuntu-sru if required
[13:37] <ScottK> Thanks.  I will.
[13:38] <seb128> jdong or slangasek or cjwatson
[13:41] <ScottK> cjwatson: I've just filed Bug #691068 in preparation for exercising the point microversion update exception for KDE for the first time.  I'm going to be reviewing and uploading them starting shortly.  I was wondering if I could have permission to also do the accept once they are all uploaded.  KDE packages have a sequence they build in and I'd like to dribble them in in such a way as they don't flood the buildds.
[13:41] <tkamppeter> cjwatson, thank you very much.
[13:43] <cjwatson> ScottK: hm, I never accept my own uploads as a matter of policy - do they not have suitable build-depends?
[13:43] <cjwatson> if you give me the sequence I would be happy to follow it
[13:44] <ScottK> cjwatson: They do, but due to soyuz funkyness uploading all at once results in a lot of FTBFS that have to be retried.
[13:44] <ScottK> OK.
[13:44] <cjwatson> wow, that's crazy
[13:44] <cjwatson> OK then ...
[13:45] <ScottK> For lucid we can probably upload them in reverse order and not accept kde4libs until everything is depwait.  Then it should ~work.
[13:45] <cjwatson> well, I'll be around for maybe seven hours yet
[13:45] <ScottK> Unfortunately the wiki doesn't version attachements.  The current order for Natty is https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph.
[13:45] <ScottK> OK.
[13:46] <cjwatson> (except that I need to go and resupply on rewritable DVDs)
[13:46] <ScottK> With the exception of meta-kde not being relevant for Lucid that should be approximately correct for Lucid.
[13:47]  * cjwatson fails to understand the positioning of meta-kde in that graph
[13:48] <cjwatson> (also it's kde4libs rather than kdelibs, right?)
[13:48] <ScottK> Yes.
[13:49] <ScottK> That hasn't changed, we just tend to know that one (the bzr packaging branches are under kdelibs)
[14:13] <ScottK> cjwatson: I've started uploading, so you can start accepting.  As long as we don't get kde4libs in before everything hits depwait, order isn't terribly significant (we lost this feature later when we improved the packaging and I'd forgotten about it)
[14:17] <cjwatson> ScottK: so I do the lot but kde4libs *last*?  seems counter-intuitive, but OK ...
[14:18] <ScottK> cjwatson: There's an oddity of soyuz that it will fail a build if a build-dep is uninstallable (or something close to that), but if it isn't present in sufficent version will depwait.  Once it's in depwait, if the build-dep is uninstallable it just goes back to depwait.
[14:19] <cjwatson> ah, gotcha
[14:21]  * cjwatson accepts kdeplasma-addons to see how that goes
[14:22] <cjwatson> tseliot: would something like http://paste.ubuntu.com/544440/ be OK for you?
[14:22] <cjwatson> as a rough structure for a way to blacklist things from gfxpayload=keep based on whether they have the proprietary drivers installed
[14:22] <mdeslaur> cyphermox: sorry for yesterday...do you still need my gconf file?
[14:25] <cyphermox> mdeslaur, well, mostly just to know which one, but if you can tell me what it looked like when it failed it would help me test failure and resolution
[14:26] <mdeslaur> cyphermox: I'll email it to you, hold on a sec
[14:26]  * tseliot has a look at the patch
[14:26] <cyphermox> mdeslaur, however, I do have the updated evolution-data-server ready in my PPA now, just want to test that your migration issue is really fixed... for the calendar stuff it is, I checked :)
[14:27] <mdeslaur> cyphermox: well, I can't migrate a second time :(
[14:29] <cyphermox> nah, that's fine, I'll try to reproduce the issue and force migration again
[14:29] <cyphermox> I may still have a pre-migration backup
[14:29] <mdeslaur> cyphermox: I don't know what old version of evo added the URI to gconf...it may have been older than maverick
[14:29] <cyphermox> ok
[14:30] <tseliot> cjwatson: it looks fine to me. I've noticed that you put a "v" at the beginning of the pci id (v10ded0298.*). Maybe I should have a look at your update-grub-gfxpayload script to see how it parses expressions in the blacklist file
[14:31] <mdeslaur> cyphermox: have you managed to reproduce not being able to mark the junk folder as read?
[14:31] <cyphermox> mdeslaur, can you remind me the bug number? I don't recall that one
[14:33] <cjwatson> tseliot: it's vVENDORdDEVICEsvSUBVENDORsdSUBDEVICEbcBASECLASSscSUBCLASS
[14:33] <cjwatson> with regex-matching
[14:33] <cjwatson> ebroder did that bit
[14:33] <mdeslaur> cyphermox: bug 690036
[14:35] <tseliot> cjwatson: ok, I can definitely include your patch in my git branch and do the same for other drivers (nvidia-96, nvidia-173 and fglrx). Thanks
[14:36] <cjwatson> tseliot: http://paste.ubuntu.com/544450/ is the core grub-gfxpayload-lists package
[14:36] <cjwatson> tseliot: let's only blacklist cards when we know it's necessary though
[14:37] <tseliot> cjwatson: it's good to see that it's documented in the code :)
[14:37] <cjwatson> do you think this structure will meet our needs?
[14:38] <cyphermox> mdeslaur, right now, I'm not successfully marking any folder as read
[14:38] <tseliot> cjwatson: yes, of course but still it's good to know that, as our last resort, we can use a regex to blacklist all of the cards from the same vendor
[14:38] <cjwatson> tseliot: oh, I missed a bit, you need to run update-grub-gfxpayload (if it exists) on removal as well
[14:38] <cjwatson> prerm probably
[14:38] <mdeslaur> cyphermox: oh! my other folders work
[14:38] <cjwatson> are we right in the basic assumption that problems are often hardware-specific?
[14:38] <cjwatson> it's very hard to say what the scope of the bugs are
[14:39] <tseliot> cjwatson: right, whenever I update the initramfs would be fine. Maybe I should do it in Jockey too (in case the package is already installed but disabled)
[14:39] <cyphermox> mdeslaur, wait, it works, but evo is not playing nice.
[14:39] <cjwatson> tseliot: mm, in that case you'll need to move the blacklist file around ...
[14:39] <cjwatson> update-grub-gfxpayload currently just picks up anything in /usr/share/grub-gfxpayload-lists/blacklist/
[14:39] <cjwatson> do I need to be more selective there or something?
[14:40] <tseliot> cjwatson: I can make it a slave link to an already existing alternative, as I already do with the module blacklist
[14:41] <kirkland> kenvandine: howdy;  right clicks and menus are invisible for me in natty/unity ... ideas?
[14:41] <kirkland> kenvandine: been that way for ~2 days now
[14:41] <kirkland> kenvandine: works okay in gnome
[14:42] <kenvandine> seb128, ^^
[14:42] <kenvandine> i saw you guys talked about that, but i didn't follow it closely :)
[14:42] <seb128> kirkland, there was several discussions about that since yesterday
[14:42] <seb128> kirkland, do you know when it started exactly and what you upgraded before?
[14:42] <seb128> we are trying to get a clue what happens
[14:42] <seb128> neither unity or compiz changed recently
[14:43] <kirkland> seb128: i think it started yesterday morning very early
[14:43] <kirkland> seb128: i was without menus all day yesterday for sure
[14:43] <seb128> can you check what was in your upgrade run before the issue started?
[14:43] <dholbach> cjwatson, I filed bug 691102
[14:43] <seb128> like copy your dpkg.log online?
[14:43] <kirkland> seb128: might have started yesterday morning, or possibly late the night before
[14:45] <cjwatson> dholbach: thanks
[14:46] <kirkland> seb128: okay: pbget http://pastebin.com/chazt1e6 > /tmp/dpkg.log
[14:47] <kirkland> seb128: it's very large (2M) so I used pbput/pbget, which compresses and uuencodes it before pastebin'ing it
[14:48] <seb128> kirkland, hum ok, thanks
[14:50] <tseliot> cjwatson: to answer your question, I think that would be flexible enough to do what we need
[14:51] <cjwatson> tseliot: ok, good
[14:59] <seb128> ok
[14:59] <seb128> so people having menu issues
[14:59] <seb128> could you try to downgrade to https://launchpad.net/ubuntu/+source/compiz/1:0.9.2.1+glibmainloop3-0ubuntu1
[15:00] <seb128> and see if that fix those after a session restart?
[15:05] <kirkland> seb128: okay, sure
[15:05] <kirkland> seb128: btw, that same logfile ... http://paste.ubuntu.com/544454/
[15:06] <kirkland> seb128: in case you didn't use pbget
[15:06] <seb128> kirkland, thanks, I think we are ok with update logs, we got some
[15:06] <seb128> including yours ;-)
[15:08] <kirkland> seb128: okay, downgraded, logging out now
[15:08] <seb128> ok
[15:11] <kirkland> seb128: uh oh, that's way worse
[15:11] <kirkland> seb128: now i don't have any launcher or anything
[15:12] <seb128> unity --reset?
[15:12] <hallyn_> kirkland: interesting, i think the pattern for me was that with the -9 kernel i got menus, and with -7 i didn't...
[15:12] <hallyn_> maybe that was purely spurious :)
[15:14] <kirkland_> seb128: ah, okay, unity --reset restored sanity
[15:14] <kirkland_> seb128: and yes, now i have menus
[15:14] <kirkland_> hallyn_: interesting;  what versions of compiz are you running?
[15:14] <kirkland_> hallyn_: as downgrading that has improved matters for me
[15:14] <hallyn_> kirkland_: whatever the latest was after the sudo upload last night :)
[15:14] <kirkland_> hallyn_: heh, okay, me too
[15:15] <hallyn_> kirkland_: btw, when you have a moment, opinion q on kvm
[15:15] <kirkland_> hallyn_: hit me
[15:16] <hallyn_> well, someone begged today to backport 0.12.5 to lucid.  Now, I'm pretty sure mahmoh has been pounding 0.12.5 on lucid for a month or two now, so while normally i'd say no, i'm wondering whether we should just do it
[15:16] <kirkland_> hallyn_: where do they want it to land?
[15:16] <kirkland_> hallyn_: i'd recommend ~ubuntu-virt's PPA for starters
[15:16] <seb128> kirkland: thanks, you are the second to confirm that downgrading compiz fix it
[15:16] <kirkland_> seb128: np;  thanks for the help
[15:16] <kirkland_> hallyn_: that has long been the destination for mostly-stable backports of kvm
[15:17] <kirkland_> hallyn_: see the kvm-84 backport for hardy
[15:17] <kirkland_> hallyn_: we could also pursue lucid-backports
[15:17] <hallyn_> kirkland_: i'll take a look at ~ubuntu-virt, thanks
[15:17] <kirkland_> hallyn_: which has only a *slightly* wider audience, but involves significantly more work to push it there
[15:17] <hallyn_> that does feel more comfortable
[15:18] <kirkland_> hallyn_: yeah, i kinda like that ~ubuntu-virt is typically only found by people who really need/want it
[15:18] <kirkland_> hallyn_: -backports is stumbled upon by all sorts of random users
[15:18] <kirkland_> hallyn_: is there a known bug or feature in particular that people want out of 0.12.5?
[15:18] <kirkland_> hallyn_: or just general stability?
[15:18] <kirkland_> hallyn_: (like mahmoh and yourself, I'm pretty happy with 0.12.5)
[15:21] <psusi> cjwatson: I noticed last night on natty that the plymouth screen looks terrible.  I think this is because of the gfx_keep_payload change in grub leaving plymouth running the screen in 640x480.  Any ideas on fixing that?  Seems like grub needs to use the correct resolution or not keep_payload.
[15:22] <cjwatson> psusi: already improved in grub2 1.99~20101210-1ubuntu1
[15:22] <cjwatson> (which should have been in the archive already, but failed to be because of launchpad librarian downtime - sorting that out now)
[15:22] <psusi> oh goody... how? ;)
[15:22] <cjwatson> grub now does vbe resolution autodetection as best it can
[15:22] <psusi> ohh... nifty
[15:22] <cjwatson> you should get the closest mode that's no larger than the preferred mode claimed by your vesa bios
[15:23] <cjwatson> (sometimes the preferred mode is not in fact in the vbe mode list.  blame your bios manufacturers for that piece of genius)
[15:23] <psusi> heh
[15:23] <hallyn_> kirkland_: there were specific bugs he cited
[15:23] <kirkland_> hallyn_: okay
[15:23] <psusi> here's to hoping my bios correctly reads the edid info and reports that as the preferrred mode
[15:23] <cjwatson> so it might still not look brilliant - my laptop has a 1280x800 panel but the closest resolution in vbe is 1024x768
[15:24] <kirkland_> hallyn_: well for specific bugs with specific commits, we can obviously cherry pick and get an SRU out
[15:24] <cjwatson> but it should be better than 640x480
[15:24] <kirkland_> hallyn_: otherwise, just upload to ~ubuntu-virt
[15:24] <cjwatson> some bioses don't manage to report decent edid, some do :-/
[15:24] <kirkland_> hallyn_: i think that would be a real good idea, actually
[15:24] <hallyn_> like virtio corrupting >1Tb disks
[15:24] <kirkland_> hallyn_: oh.  well that's SRU material
[15:24] <cjwatson> grub tries edid followed by the vbe flat panel extension, which is roughly the same logic used by xserver-xorg-video-vesa
[15:24] <hallyn_> i beg to disagree about 'obviously cherry pick'  :)
[15:24] <psusi> so since it isn't in the vbe mode table at all, it just isn't possible for grub to go to 1280x1024 right?  even if you set the config file up to use that resolution?
[15:24] <cjwatson> correct, unfortunately
[15:25] <hallyn_> when the code bse totally changes underneath you ...
[15:25] <cjwatson> at least not without importing something equivalent to kernel modesetting
[15:25] <hallyn_> yeah ill upload to ~ubuntu-virt
[15:25] <psusi> blast
[15:25] <kirkland_> hallyn_: okay, you're on ~ubuntu-virt now
[15:25] <hallyn_> cool, thanks.  i'll see what i can do with that
[15:25] <cjwatson> however, it would be fixable by a bios rev
[15:25] <psusi> now... a side effect of the higher resolution is making the font used on the boot menu smaller isn't it?
[15:25] <cjwatson> probably, I haven't looked much at that yet
[15:26] <cjwatson> up to a certain point that's an improvement of course
[15:26] <kirkland_> hallyn_: how many git commits are there between 0.12.3 and 0.12.5?
[15:26] <cjwatson> it's a bit big and chunky on 640x480
[15:26] <psusi> I think the last time I tried using the higher resolutions that happened because grub uses raster fonts, so it needs to load a larger raster font for higher resolutions or it is hard to read
[15:26] <kirkland_> hallyn_: (you don't have to answer that question now, unless you have git in front of you)
[15:26] <cjwatson> I'm not too desperately worried about that for the meantime
[15:27] <kirkland_> hallyn_: you know, if it's a handful (maybe 10 or less?  i don't know ...)  we could consider grabbing the set and adding them to lucid's
[15:27] <kirkland_> hallyn_: i suspect its a lot more than that
[15:27] <psusi> for the meantime meaning testing during the development cycle?  or you would be ok going to release with hard to read boot menu?
[15:27] <kirkland_> hallyn_: aliguori takes a lot of "stabilization" patches :-)
[15:28] <cjwatson> the latter, TBH
[15:28] <cjwatson> it doesn't seem hard to read on any hardware I have
[15:28] <cjwatson> maybe if you have a 1920x1280 panel or something
[15:28] <psusi> 1280x1024 makes the default font quite small ;)
[15:28] <cjwatson> (or whatever it is)
[15:29] <smb> cjwatson, Is it possible to have the "daily" lucid install images rebuild with the current updates kernel? There is bug 546091 which depends on the updated kernel being in the installer and the last build seems to have been Nov-24.
[15:29] <psusi> but I suppose that is better than flickering or ugly plymouth screen
[15:29] <hallyn_> kirkland_: unfortunately i don't have the tree in front of me, but i remember looking at what it would take to cherrypick some of those, and it was huge
[15:29] <psusi> maybe I'll take a look at having grub switch to a larger font when it is using a higher resolution
[15:29] <hallyn_> definately not LTS material - that is, cherry-picking would be more dangerous than taking the maveick version, imo
[15:29] <cjwatson> psusi: if you want to, sure
[15:29] <kirkland_> hallyn_: yeah, it was more a thought exercise
[15:29] <cjwatson> smb: sure, give me a minute
[15:29] <kirkland_> hallyn_: right, agreed
[15:30] <kirkland_> hallyn_: "data corruption" though, is LTS material
[15:30] <smb> cjwatson, no worries. thanks.
[15:30] <kirkland_> hallyn_: even if it means asking aliguori for some assistance selecting the patches that need to be in the cherry pick
[15:30] <hallyn_> kirkland_: > 1tb disk though
[15:30] <hallyn_> hm
[15:31] <hallyn_> kirkland_: maybe we shouldadd a 'wantSRU' tag to the ones we want to find some way to apply to lucid
[15:31] <hallyn_> (so i can find them again all at once and amke notes)
[15:31] <nemo> Anyone noticed unusually high memory usage in Xorg over time?  Seems to have become more severe with 10.10.   Trying to think of ways to debug it.
[15:32] <psusi> now if I could find someone who knows about pulseaudio and how it is initialized to shed some light on why the login sound can start to play before pulseaudio is ready so it is cut off or not heard at all...
[15:32] <nemo> Stays high if I quit all apps and killall nautilus.  I'm about to try binding in gdb again.
[15:32] <nemo> Last time I tried this it locked up my machine hard (yes, completely).  Wondering if anyone might have any other ideas
[15:32] <hallyn_> kirkland_: well, 95 commits between 0.12.3 and 0.12.5
[15:32] <nemo> (my theory is that I can try dumping memory in gdb and examining contents for clues)
[15:32] <kirkland_> hallyn_: yeah, that's huge;  too much for an SRU
[15:32] <hallyn_> it's less than i thought it was :)
[15:33] <nemo> top line after a killall of nautilus.   1239 root      20   0 1625m 893m  86m S    3 23.3   2115:22 Xorg
[15:33] <kirkland_> hallyn_: tags are good, yeah
[15:33] <hallyn_> all right, back in a flash - i need to sync my U1 befor my trip, or i'm in bad shape next week
[15:33] <kirkland_> hallyn_: at least when aliguori was running ubuntu a lot, he'd poke me when he saw a mission critical stable commit come across, that he thought we'd want to SRU
[15:33] <kirkland_> hallyn_: word, thanks.
[15:34] <kirkland_> hallyn_: you can probably just take mahmoh's 0.12.5, update the version appending a ~ppa1 on it, and dput to the ~ubuntu-virt ppa
[15:35] <hallyn_> kirkland_: ok, cool.  so first i'll do the ppa, then i'll just try to cherrypick the critical ones and talk to aliguori if i must.  (tbh my impression had been that he really was not interested in helping with that, but i'll see)
[15:36] <cjwatson> smb: wait.  that bug is claimed to be fixed in linux 2.6.32-26.47.  the installer on the current lucid CDs was built against linux 2.6.32-26.47.  what difference would rebuilding make?
[15:36] <kirkland_> hallyn_: let's take him out for a beer :-)
[15:37] <hallyn_> some vodka diplomacy
[15:37] <seb128> could someone binNEW gdk-pixbuf girs to main for me? it's blocking the gtk rebuilds for the gir transition
[15:38] <seb128> (I don't want to NEW my own upload but it should be trivial)
[15:39] <smb> cjwatson, Hm in that case none. I assumed they were build before. I'll need to check closer then. Sorry for the noise
[15:43] <tkamppeter> cjwatson, seb128, I have posted a MIR for pyppd now (bug #691133). Should I already modify foomatic-db to build-depend on pyppd? Or have I to wait for the MIR being approved?
[15:44] <seb128> tkamppeter, better to wait for the mir to be approved or you will break installations
[15:45] <seb128> jdstrand, there?
[15:45] <jdstrand> seb128: ?
[15:46] <seb128> "could someone binNEW gdk-pixbuf girs to main for me? it's blocking the gtk rebuilds for the gir transition
[15:46] <seb128>  (I don't want to NEW my own upload but it should be trivial)"
[15:46] <jdstrand> seb128: sure, I'll take care of it
[15:46] <seb128> jdstrand, ^ sorry to direct ping, I just would like to catch the next publisher run
[15:46] <jdstrand> np
[15:46] <seb128> I want to get that transition through today and we still need to build gtk and then other things after gkt
[15:46] <seb128> gtk
[15:46] <seb128> jdstrand, thanks!
[15:46] <kibibyte> hi
[15:47] <kibibyte> why ubuntu package maintainers doesnt create any libreoffice package
[15:47] <seb128> kibibyte, hey
[15:47] <seb128> because it's quite some work and nobody had time for it
[15:47] <ion> kibibyte: Feel free to contribute.
[15:47] <seb128> but if you want to work on that you are welcome to do it
[15:48] <jdstrand> seb128: I see a gir gconf and gir json-glib too. also needed?
[15:49] <seb128> jdstrand, yes
[15:49] <seb128> jdstrand, to main please
[15:49] <seb128> jdstrand, thanks ;-)
[15:49] <jdstrand> sure
[15:49] <jdstrand> working on it now
[15:49] <kibibyte> but seb128 then whu you fixing shitty openoffice instead of drop it and take care of libreoffice
[15:50] <seb128> kibibyte, there is nobody working on openoffice either
[15:50] <seb128> kibibyte, there is an open position at Canonical for it though
[15:50] <seb128> kibibyte, you are welcome to apply if you are interested
[15:51] <kibibyte> is it remote?
[15:51] <kibibyte> based
[15:51] <seb128> yes
[15:51] <kibibyte> hm
[15:51] <cjwatson> I'd recommend a more constructive approach than "shitty" though!
[15:51] <jdstrand> heh
[15:51]  * jdstrand is still chuckling
[15:52] <zul> can someone accept tftp-hpa into proposed for me?
[15:53] <ScottK> cjwatson: There's another 7 in the queue when you have a moment.
[15:54] <cjwatson> oh yeah, sorry, too many things going on at once
[15:57] <jdstrand> seb128: accepted json-glib, gconf, and gdk-pixbuf to main
[15:57] <seb128> jdstrand, thanks a bunch
[15:57] <seb128> on time for the publisher run ;-)
[15:57] <jdstrand> seb128: sure! :)
[15:58] <kibibyte> is it har to create package for libreoffice?
[15:58] <kibibyte> hard
[15:58] <kibibyte> i just did once simple package
[15:59] <jdstrand> I think that Canonical having a dedicated position for packaging and maintaining openoffice.org is an indication it is non-trivial
[15:59] <jdstrand> put another way. yes
[16:00] <highvoltage> kibibyte: doing any kind of decent libreoffice packages is a lot of work
[16:00] <cjwatson> without wishing to disparage any other package, openoffice.org is probably the single most complex package in the archive
[16:00]  * jdstrand unfondly remembers oo.o security updates :)
[16:00] <cjwatson> how much that simplifies with libreoffice, I'm not certain; there are packages in Debian experimental
[16:01] <joaopinto> hey, that teasing someone to quit a job to package oo :P
[16:10] <cjwatson> ScottK: FAILED: kdepim (The source kdepim - 4:4.4.8-0ubuntu1 is already accepted in ubuntu/natty and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload.)
[16:11] <ScottK> cjwatson: Thanks. Sorry about that.  Please reject kdepim-runtime as well.
[16:11] <cjwatson> done
[16:24] <ScottK> cjwatson: Both reuploaded.  Those should be the only ones at risk for that kind of problem.
[16:31] <hallyn_> kirkland: hye, i tried pushing vmbiulder using 'bzr merge-upstream' like you suggested, but got:
[16:32] <hallyn_> bzr: ERROR: Merge upstream in merge mode is not yet supported.
[16:32] <kirkland> hallyn_: doh
[16:32] <kirkland> hallyn_: might need to chat with james_w, jelmer, or #bzr
[16:33] <hallyn_> i'll try #bzr, thanks
[16:47] <glicks> hi
[16:47] <dholbach> apw, seems like the texlive-extra build failed
[16:47] <dholbach> http://launchpadlibrarian.net/60746119/buildlog_ubuntu-natty-i386.texlive-extra_2009-10ubuntu1_FAILEDTOBUILD.txt.gz
[16:47] <dholbach> (something to do with pkgstripfiles)
[16:48] <glicks> hi, i was wondering, is there something like YaST2 available for Ubuntu that allows easy starting, stoping, configuration, and scheduling of services from a easy GUI?
[16:49] <glicks> and if not is that something that might be in the works
[16:49] <glicks> or is that a suggestin i can make
[16:52] <hallyn_> kirkland: all right, seems what we wanted is not quite possible
[16:52] <kirkland> hallyn_: vmbuilder, you mean?
[16:52] <hallyn_> dholbach: james_w: hi, I was wondering what exactly woudl be involved in my geting upload rights for the vmbuilder project?  :)
[16:52] <hallyn_> kirkland: yeah
[16:52] <glicks> anyone?
[16:53] <hallyn_> kirkland: final answer was that all I can do is build te source package and upload it (like we did last time)
[16:53] <dholbach> hallyn_, https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage
[16:53] <hallyn_> dholbach: thanks
[16:53] <dholbach> de nada
[16:53] <hallyn_> (i thought iw as looking at that page yesterday, but somehow missed the per-package section)
[16:53] <kirkland> hallyn_: alrighty then ... bummer.  we'll play by thems rules
[16:56] <hallyn_> zul: would you mind sponsoring people.c.c/~serge/vm-builder-461.tgz ?  (contains the source package)
[16:58] <glicks> are there any plans for an ubuntu GUI based services manager/configurator?
[16:58] <glicks> sort of like yast2 on suse?
[16:58] <zul> hallyn_: sure as soon as lunch is done
[16:58] <hallyn_> zul: thanks!  i'll owe you a red bull in dallas :)
[17:02] <charlie-tca__> glicks: I don't know yast2, but as a suggested improvement, that might be better presented on brainstorm - http://brainstorm.ubuntu.com/
[17:03] <glicks> i see charlie-tca__ thanks.  I think a yast2 like interface would add alot of polish to ubuntu, basically its a interface to configure, schedule, start and stop system services and firewalls from a nice easy GUI
[17:03] <charlie-tca__> um, that might be ufw
[17:04] <james_w> glicks, there was a GSoC project for the services part this summer
[17:04] <glicks> GSoC?
[17:04] <jelmer> Google Summer of Code
[17:04] <glicks> oh google
[17:04] <glicks> yeah
[17:04] <glicks> hmm
[17:04] <james_w> https://launchpad.net/jobsadmin
[17:05] <james_w> apt-get install jobs-admin
[17:12] <maxb> mvo: Hi, around? I just tried a maverick->natty update-manager upgrade, and it died because it didn't disable ppa.launchpad.net sources in my sources.list
[17:13] <mvo> maxb: I'm about to leave for dinner, but could you please mail me the logs in /var/log/dist-upgrade/* ? I have a look then
[17:17] <maxb> mvo: Actually, I suck, I'd forgotten about an /etc/update-manager/release-upgrades.d/allow-third-party.cfg left over from lucid->maverick
[17:19] <mvo> maxb: ok, no worries
[17:23] <lool> Is there a place where ddebs.ubuntu.com issues are typically tracked?
[17:23] <lool> e.g. missing packages, or bugs
[18:02] <ScottK> cjwatson: Everything execpt kde4libs and oxygen-icons (which doesn't depend on anything else and can be accepted anytime) is done.  I'd appreciate it if you could take another pass at accepting.
[18:10] <hallyn_> kirkland: ok, so the menu thing is just random.  i just rebooted, and now have no menus
[18:10] <micahg> ari-tczew: re webkit merge, does the version currently in natty still build?  If so, try disabling the new Debian patches to see if it builds then
[18:10] <hallyn_> cjwatson: ^
[18:11] <ari-tczew> micahg: current also ftbfs
[18:11] <zul> hallyn_: done
[18:12] <cjwatson> ScottK: done
[18:12] <ScottK> cjwatson: Thanks.
[18:12] <cjwatson> hallyn_: hmm?  I haven't been following this.  (also, off to dinner now)
[18:14] <kirkland> hallyn_: you're looking for seb128
[18:14] <kirkland> hallyn_: he's gone, though
[18:14] <hallyn_> zul: thanks!
[18:14] <hallyn_> cjwatson: oops, sorry
[18:14] <hallyn_> i scrolled up and apparently misread :)
[18:26] <micahg> ari-tczew: re: webkit, looks like there's a gir transition in progress, can you attach a branch to that bug with what you have from the merge, I can try to take a look later if no one else gets to it first
[18:27] <ari-tczew> micahg: branch attached a few minutes ago. it looks like I'm reading in your brain but my reaction is faster ;-)
[18:27] <micahg> ari-tczew: heh, ok, thanks
[18:29] <kees> cjwatson: say, any thoughts on bug 690030 ? I don't even know where to begin to debug it.
[18:30] <smoser> @pilot out smoser`
[18:30] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[18:30] <smoser`> @pilot out
[18:39] <kirkland> hallyn_: i just dist-upgraded to natty, held my breath, rebooted, and i'm up and running with a functional unity desktop again
[18:40] <dwalker> hi everyone, not sure if this is the right chan to post this question, but I'm looking into preseeding a server install from (https://help.ubuntu.com/10.04/installation-guide/hppa/preseed-using.html) and the first paragraph says to look at the developers' documentation for debian-installer.  I've scoured for a while not able to find it.  Anyone know where the docs for it are located?
[18:42] <ScottK> cjwatson: I had to reupload kdebindings and kdebase due to forgetting to include the tarball.  They are waiting for you ....
[19:00] <hallyn_> kirkland: jinkeys!  you were having that trouble in maverick?
[19:00] <kirkland> hallyn_: no ...
[19:00] <kirkland> hallyn_: natty
[19:00] <hallyn_> 'dist-upgraded to natty' ?
[19:00] <kirkland> hallyn_: dist-upgraded to latest natty
[19:01] <hallyn_> oh :)
[19:01] <kirkland> hallyn_: from slightly less than latest natty
[19:01] <hallyn_> well, give it a few reboots :)
[19:01] <hallyn_> i thought i was past the menu thinguntil this lastest boot
[19:40] <cjwatson> dwalker: apt-get install debian-installer
[19:41] <cjwatson> kees: ok, I'll look in a bit
[19:41] <dwalker> cjwatson: i'm really looking for a guide on what all the d-i options are for preseeding
[19:42] <cjwatson> dwalker: the useful ones should all be in the installation-guide
[19:42] <cjwatson> there are lots of internal ones - a full dump would confuse more than help
[19:43] <dwalker> the installation-guide seems a bit sparse when it comes to all the partman-auto settings, is there a more drilled down guide on those?  I've been scouring the net for examples and got most of what I need, but the partman recipes are a bruiser
[19:45] <cjwatson> dwalker: yes, /usr/share/doc/debian-installer/devel/partman-auto-recipe.txt.gz in the debian-installer package
[19:45] <cjwatson> ScottK: done all but kde4libs - let me know when it's safe to accept that?
[19:45] <dwalker> score
[19:46] <cjwatson> kees: tell me (or the bug) about the disk layout on this system?
[19:46] <ScottK> cjwatson: Thanks.  If you'd please rescore kdebase and kdebindings so they can jump the queue on get to depwait on powerpc, that would move things along (sorry about the need for the double upload).
[19:46] <cjwatson> sorry, being called away to deal with toddler
[19:46] <cjwatson> in an urgent tone of voice
[19:46] <ScottK> Understand.  Good luck.
[19:56] <ScottK> doko or NCommander: Would you please rescore kdebindings and kdebase since cjwatson's been called away (this is on Lucid).
[19:59] <ScottK> Nevermind.
[20:00] <ScottK> They're coming up faster than I thought.
[20:08] <ScottK> cjwatson: I found one more that I'd missed the orig.tar.gz on and had to re-upload (kdeutils).  Please accept that one when the toddler situation permits.
[20:10] <micahg> ScottK: are there any plans to SRU KDE point releases in maverick as well?
[20:10] <ScottK> micahg: Yes.
[20:10] <micahg> ScottK: cool
[20:10] <ScottK> Probably not until after the last one though.
[20:10] <micahg> ScottK: you mean until 4.5.x is EOL?
[20:11] <ScottK> micahg: Normally KDE does 4 or 5 point updates and moves on.
[20:11] <micahg> ScottK: so, not incremental updates, just one final update
[20:11] <ScottK> IIRC 4.5.4 just come out.
[20:12] <ScottK> We'll package all the intermin versions in ~kubuntu-ppa for testing.
[20:12] <ScottK> interim ....
[20:13] <micahg> ScottK: I assume that PPA is fairly stable then?
[20:13] <ScottK> Mostly.
[20:13] <micahg> ok, maybe I'll just add that then
[20:13] <ScottK> We at least smoke test them before putting them in the PPAs.
[20:13] <ScottK> Testing feedback is useful.
[20:14] <dwalker_> cjwatson: not sure if your good with the partman stuff in the debian-installer but is there a way to create a recipe for it that defines partitions on different disks?  All the examples in the documentation are really suited for 1 drive, or doing RAID over multiple disks.  Not much of a use /dev/sda for /, and /boot, but /dev/sdb for /home
[20:25] <Shayon> Hi I am wondering what programming laguages are required or one should know in order to start developing . I know it depends on personal preference and interest . But right now I am just a student (freshmen) and looking for some guidance :P
[20:29] <nemo> Shayon: personally I think people learning to develop should start with a high level intepreted language or a low level language like C
[20:30] <Shayon> nemo, i see. thanks :)
[20:30] <Shayon> i started with c++
[20:30] <nemo> ah
[20:30] <nemo> IMO that's a rough place to start
[20:30] <nemo> C++ is rather complex
[20:31] <Shayon> then you mean c /?
[20:31] <dwalker_> though it seems like many colleges are teaching either java or c++ as the intro languages
[20:31] <Shayon> i guess java is def. hig end
[20:31] <nemo> dwalker_: I'd say java is a better intro language
[20:31] <nemo> dwalker_: fewer surprises
[20:31] <Shayon> not*
[20:31] <nemo> dwalker_: we started with C at my college. although I understand they have switched to java now
[20:32] <dwalker_> nemo: meh, I'm self taught C when I was 12, I figure if you can't learn it yourself it's a long uphill battle.
[20:32] <nemo> but I think just for learning, oh, data structures and whatnot, hell, you could start with javasciprt
[20:32] <nemo> now that javascript has types
[20:32] <Shayon> dwalker_, 12 ? Well thats sweet :)
[20:32] <nemo> dwalker_: mm. my first language was pascal - mom shipped me off to local community college when my bro was 9 and I was 10
[20:32] <nemo> we struggled
[20:32] <nemo> dwalker_: I self-taught visual basic
[20:32] <nemo> er
[20:33] <nemo> basic
[20:33] <nemo> there was no visual back then :)
[20:33] <nemo> I still have some of my programs from when I was a kid :)
[20:33] <dwalker_> ummm pascal
[20:33] <nemo> dwalker_: I use it a lot today, amusingly
[20:33] <nemo> on Hedgewars
[20:34] <dwalker_> I've recently gotten a haskell fettish developing.
[20:34]  * xnox javascript self-taught grasshops at 11
[20:35]  * xnox later pascal at a CS after-school club at 16
[20:35] <xnox> dwalker[afk], hmmmm I want to try Haskell one day  =) my last fettish was ObjC
[20:36] <ScottK> nemo: For Ubuntu development C, Python, and C++ are probably the most useful.
[20:36] <nemo> dwalker[afk]: hedgewars also uses haskell :)
[20:37] <nemo> dwalker[afk]: server is haskell, engine is pascal
[20:37] <nemo> ScottK: well. Python satisfies "high level" and C "low level"  - I just would not suggest people start with C++
[20:37] <nemo> they might get some odd ideas
[20:38] <ScottK> Depends.  If you want to develop for KDE, the C ideas are the odd ones.
[20:42] <nemo> Qt is not exactly C++ either :)
[20:42] <nemo> ScottK: I'm just saying the advantage of C is you learn 'sactly what is doing what in a computer
[20:42] <nemo> and high level, you get to focus on language concepts
[20:42] <nemo> but C++ is just an odd mix
[20:46] <udienz> doco: i send review request at bugs 514401
[20:46] <udienz> thankss before
[20:48] <hallyn_> kirkuh,yeah.  so i updated my natty netbook, and now have no termcap entries :)  i have to ctrl-m instead of return
[20:48] <hallyn_> kirkland: ^ and no tab apparently either :)
[20:50] <hallyn_> neat thing is byobu can't update the status line the right way, so status keeps jumping another line up every second
[20:50] <hallyn_> well this just won't do
[20:51] <kees> cjwatson: bug updated. thanks!
[20:52] <kirkland> hallyn_: wait, what?  huh?
[20:58] <hallyn_> kirkland: http://pastebin.com/jepjqs0B
[20:59] <hallyn_> seems to be *** VTE ***: Failed to load terminal capabilities from '/etc/termcap'
[20:59] <hallyn_> thta is, seems to show up once in awhile in launchpad
[21:06] <hallyn_> kirkland: you've still got menus?
[21:06] <hallyn_> dist-upgrade+reboot, but still no menus here
[21:11] <tumbleweed> seb128: bug 685584, can you enumerate the tweaks required? (The patch since your comment looks fine to me)
[21:12] <seb128> tumbleweed, it is, you can sponsor if you want
[21:12] <seb128> the update just came after the end of my work day
[21:12] <tumbleweed> seb128: aah, you weren't subscribed so I assumed you weren't following it
[21:13] <tumbleweed> uploaded
[21:14] <seb128> tumbleweed, thanks
[21:17] <ari-tczew> tumbleweed: I guess that you have less to do in SQ this cycle :>
[21:18] <tumbleweed> ari-tczew: the queue is in fantastic shape :)
[21:19] <ScottK> cjwatson: Whenever you can take another pass at lucid-proposed, just go ahead and accept kde4libs and kdeutils at the same time.  Worst case I'll have a couple of retries to do.  Most likely it'll be just fine.  Thanks again.
[21:20] <ari-tczew> tumbleweed: the most contributing people in maverick have been joined to motu in one time - bhavi, bilal and me :P
[21:20] <ari-tczew> so you have nothing to do for us
[21:20] <ari-tczew> ah, debfx also joined motu
[21:20] <ari-tczew> and angelabad is coming
[21:21] <cjwatson> dwalker_: unfortunately partman really isn't especially good at that yet.  I personally just use LVM in those situations - makes things much easier anyway.
[21:22] <cjwatson> ScottK: meh, I should only have to wait a couple of minutes for kdeutils now so I might as well wait
[21:22] <achiang> hello, i know that there are known issues with using usb-creator to create a Lucid USB stick while hosted on Maverick; are there issues in the other direction too?
[21:22] <ScottK> cjwatson: OK.  Thanks.
[21:22] <achiang> hosted on Lucid, and trying to create a maverick USB key?
[21:22] <cjwatson> ScottK: (I assume you've seen the sparc failures)
[21:23] <ScottK> cjwatson: Yes.  Those are expected.  KDE was totally broken on sparc at release and so this isn't a regression.
[21:23]  * cjwatson nods
[21:26] <dwalker_> cjwatson: yeah I caught that in some site 8000 searches later that partman can't do multiple disks for preseed
[21:27] <cjwatson> I do kind of intend to fix that at some point, but ...
[21:30] <PetrHH> Hello, I'd like to use mysql embedded in my app and want to store database to user's directory but apparmor privets me in it. Strange is, that ~/tmp is accessible but when I create directory e.g. ~/abc, it is not. Where could be a problem, please?
[21:31] <ScottK> PetrHH: You might look at what the amarok package does.  AFAIK it uses mysqle.
[21:31] <cjwatson> ScottK: build dominoes should be starting now.  (only amd64+i386 have so far dep-waited kdeutils, but the rest should finish well before kde4libs builds and publishes and renders stuff uninstallable.  besides, I'm bored of waiting. :-) )
[21:31] <ScottK> cjwatson: Excellent.  Thank very much for taking care of it.
[21:37] <PetrHH> ScottK, I'm sorry I don't understand. Strange is that mysqld command works if I run it from ~/tmp and doesn't work when I run it from ~/abc. I double checked, directories has the same permission but apparmon won't allow mysqld to wok at ~/abc
[21:38] <PetrHH> I don't know why. I didn't change anything in apparmor configuration. Even I don't know where and how.
[21:39] <PetrHH> I have ubuntu 10.04
[21:40] <jdstrand> PetrHH: what do you mean 'run from tmp'? you put it's database there?
[21:43] <jdstrand> s/it's/its/
[21:44] <PetrHH> jdstrand, Yes, just for testing
[21:45] <jdstrand> PetrHH: yes, it will work in /tmp and not from $HOME. you can see the denied messages in dmesg
[21:45] <jdstrand> PetrHH: you have to adjust the profile
[21:45] <PetrHH> Here is the command: mysqld --defaults-file=`pwd`/my.cnf --default-storage-engine=MyISAM --datadir=`pwd` --socket=`pwd`/sock --skip-grant-tables --port=3334
[21:45] <jdstrand> PetrHH: the apparmor profile that is
[21:45] <PetrHH> jdstrand, but it works from ~/tmp
[21:45] <PetrHH> but not from ~/abc
[21:46] <jdstrand> PetrHH: yes
[21:46] <jdstrand> that is consistent with the apparmor policy
[21:46] <jdstrand> look at /etc/apparmor.d/usr.sbin.mysqld
[21:47] <PetrHH> thank you
[21:59] <PetrHH> ScottK, where I can find out it?
[21:59] <ScottK> PetrHH: apt-get source akonadi.
[21:59] <PetrHH> ScottK, thank you
[22:01] <YokoZar> slangasek: any multiarch updates?
[22:02] <YokoZar> slangasek: I'm getting asked to merge/update natty ia32-libs...
[22:11] <xnox> No patch pilot.....  I'm failing to find info on how to request a package rebuild?!
[22:12] <StevenK> xnox: Which package?
[22:12] <xnox> anjuta-extras
[22:12] <xnox> depends on older binutils that is already in natty. Rebuild makes it work.
[22:12] <xnox> s / that / than /
[22:13] <micahg> xnox: file a bug and attach a debdiff or create a branch is how to request one
[22:13] <xnox> micahg, ok, i'll do that then.
[22:13] <micahg> xnox: dch -R and describe the reason
[22:14] <StevenK> I was just going to fix it
[22:14] <StevenK> TBH :-)
[22:14] <micahg> well, that works too
[22:14] <micahg> xnox: ^^
[22:14] <xnox> StevenK, please do that. I thought there was a script to generate $version+b1 and upload it
[22:15] <xnox> but I'm not ubuntu-dev so it will be PITA to create branch, find sponsor, upload that.... =)
[22:15] <StevenK> I can't think of one, of the top of my head
[22:15] <micahg> xnox: dch -R is the scripts and a simple debdiff works
[22:16] <micahg> oh, won't upload :-/
[22:16] <xnox> StevenK, anjuta-extras is "synced from debian" although I think it should be managed by ~desktop-team, because anjuta is managed there.
[22:17] <PetrHH> ScottK, I added rule to apparmor and it works. Thank you. I looked at akonadi and found out that mysqld binary is copied to mysqld-akonadi. I'm not sure that it is good idea. What happened when original mysqld is updated? But don;t know what is better. Copying mysqld or adding my own rule to usr.sbin.mysqld file.
[22:17] <xnox> micahg, --bin-nmu is better =)
[22:17] <micahg> xnox: we don't do those :P
[22:17] <ScottK> PetrHH: jdstrand would be the one to discuss it with.
[22:17] <ScottK> jdstrand: If we could get rid of mysql-akonadi that would be marvelous.
[22:18] <jdstrand> mysqld-akonadi is currently configured to run unconfined
[22:18]  * xnox recalls a vague discussion to use +b1 version string on "ubuntu-style 'binnmu' source upload, no change, just rebuild uploads"
[22:18] <jdstrand> ScottK: I agree
[22:18] <jdstrand> don't currently have the cycles
[22:18] <jdstrand> PetrHH: ^
[22:18] <micahg> xnox: nope, build1 for native/Debian or increment Ubuntu version
[22:18] <xnox> micahg, that way it doesn't end up in the merge-o-matic next time around and continues to sync.
[22:18]  * xnox might be wrong
[22:18] <StevenK> It should continue to sync
[22:19] <StevenK> It's just a changelog entry, and it doesn't matter if it dies in a fire
[22:19] <jdstrand> PetrHH: in terms of security updates, should be fine because mysqld-akonadi would get updated
[22:19] <jdstrand> PetrHH: bottom line-- if you can add the line to your apparmor profile, that is best
[22:19] <xnox> StevenK, micahg =) ok learned something new.
[22:19] <micahg> xnox: that's why it's better to use dch -R and not worry about what it should be
[22:20] <xnox> So StevenK when can I $ sudo aptitude update && sudo aptitude install anjuta-extras from my preffered mirror from Estonia?
[22:20] <xnox> =))))))
[22:20] <StevenK> A few hours, at least
[22:21] <xnox> =(
[22:21] <PetrHH> jdstrand, thank you very much, I'll do it. My app was designed to run from $HOME and now I'm working to package it so I must do a lot of changed. Thank you for patience.
[22:56] <itachi> hello
[22:57] <itachi> can you help me??
[22:57] <d_ed> !ask | itachi
[22:58] <itachi> i wanna to install beowulf clustering without hard disk. but i dont know what services i chould install
[23:00] <micahg> itachi: that's probably a question for #ubuntu-server
[23:00] <bdrung> \o/ sponsor queue is down to 25 items
[23:10] <xnox> bdrung, https://code.launchpad.net/~dmitrij.ledkov/ubuntu/natty/htmldoc/fix-ftbfs/+merge/43393 sponsor comments fixed. Please review and upload? =)
[23:11] <bdrung> xnox: from d/changelog "Trying to fix"?
[23:11] <xnox> hmmmmm
[23:11] <xnox> bzr revert did too much =)
[23:12]  * xnox damn it
[23:12] <bdrung> xnox: enough reviewed for today. :P
[23:14] <xnox> =))))
[23:15] <micahg> xnox: why are you adding autoreconf, is that required with your change?
[23:17] <xnox> micahg, yes
[23:18] <xnox> micahg, New proposal https://code.launchpad.net/~dmitrij.ledkov/ubuntu/natty/htmldoc/fix-ftbfs/+merge/43994
[23:18] <xnox> cleaned-up version =)
[23:18] <xnox> diff is being generated.
[23:18] <micahg> xnox: sorry, I can't upload though :)
[23:19] <xnox> micahg, =)))) if you understand firefox you should be granted full upload rights ;-)
[23:19] <xnox> to *everything*
[23:19] <xnox> =)
[23:19] <micahg> xnox: I highly disagree :)
[23:20] <xnox> alright then =)
[23:21] <xnox> micahg, + AC_CHECK_LIB(X11,XCreateBitmapFromData) in configure.in needs regenerating configure scripts =) meh
[23:22] <micahg> xnox: ah, but why is that needed?
[23:22] <xnox> Fix FTBFS because of --as-needed
[23:22] <xnox> all three issues cause FTBFS
[23:22] <xnox> (well make subdir makes fail was "hiding" one of the FTBFS by not erroring out)
[23:23] <micahg> xnox: right, but adding to build-dep isn't enough, the build system needs to be patched (in Ubuntu)?
[23:23] <xnox> micahg, yes! See doko announcing on -devel "Natty toolchain changes"
[23:24] <micahg> nm, I'm still green WRT autoconf-foo
[23:24] <xnox> libtool will now only link as-needed from what is supplied on the link line.
[23:25] <xnox> if there is no -lX11 on the link line libtool will no longer "add it for you" in natty based on dependencies from dependencies.
[23:25] <micahg> xnox: ah, and the AC_CHECK_LIB is the clean way to do that
[23:26] <xnox> micahg, Consider libA <- libB <- libC. If app links against libA should it be automatically linked against libB and libC? If it uses symbols from libC but not from libB? That's what the change is about =) you have to ask to get libC.
[23:26] <xnox> micahg, yes AC_CHECK_LIB is clean way to do that. But it is not the only way to do it.
[23:27] <xnox> upstream seems to preffer AC_CHECK_LIB, I on the other hand preffer pkg-config.
[23:27] <micahg> xnox: ok, yeah, I know about the linking requirements WRT needing to be explicit, but still unsure about where/how those fixes go
[23:31] <xnox> micahg, easy =) ld tells you
[23:31] <xnox> Linking htmldoc...
[23:31] <xnox> /usr/bin/ld: gui.o: undefined reference to symbol 'XCreateBitmapFromData'
[23:31] <xnox> /usr/bin/ld: note: 'XCreateBitmapFromData' is defined in DSO /usr/lib/libX11.so.6 so try adding it to the linker command line
[23:31] <xnox> /usr/lib/libX11.so.6: could not read symbols: Invalid operation
[23:31] <xnox> collect2: ld returned 1 exit status
[23:32] <micahg> xnox: right, I get that, but how to add the dependency is where I run into issues, I just need to read a little more I think
[23:34] <xnox> micahg, http://bit.ly/eHLcbx <---- I read this every night before going to bed =)
[23:52] <xnox> good night all