[00:05] <maco> ebroder: aye?
[00:06] <maco> ebroder: i gave up on jussi's server coming back
[00:06] <ebroder> maco: Can you pull together a new debdiff for bug #415766? (I can if you're busy, but I don't want to steal the upload since you've already put work into it)
[00:07] <maco> sure
[00:08] <ebroder> maco: Cool - jdong is in the same room as me so I can harass him to upload it when you're done O:-)
[00:08] <jdong> wait what??
[00:09] <maco> haha
[00:09] <maco> ebroder: its just a version # change right?
[00:09] <ebroder> maco: AFAIK
[00:10] <maco> was the first one uploaded or not? ie, does this need a new changelog entry?
[00:10] <jdong> no
[00:10] <jdong> err
[00:10] <jdong> yes then no
[00:10] <jdong> unpack in that order
[00:11] <maco> ok then
[00:41] <smoser> slangasek, still around?
[01:02] <dtchen_> james_w: is the general push/practice for bzr usage in Ubuntu to maintain the entire source tree, not just the debian subdir, in bzr?
[01:03] <dtchen_> (or anyone else, really)
[01:03] <ScottK> I think that's the long term plan, but it's very mixed at the moment.
[01:04] <TheMuso> dtchen_: Now that git vcs imports work, it may be worth considering moving over to the entire source tree. Same with alsa, as we can then get an svn import of the alsa pieces.
[01:05] <dtchen_> TheMuso: yeah, I'm just considering how to approach this in the next two days ;)
[01:05] <cody-somerville> having everything in the same branch seems much easier to maintain
[01:06] <dtchen_> cody-somerville: in what senses?
[01:06] <cody-somerville> the code and the packaging is all in one place
[01:07] <dtchen_> these 33.6/56kbps dialup connections are horrendous for pulling/pushing branches
[01:07] <cody-somerville> thats certainly one drawback
[01:07] <maco> dtchen_: why are you on dialup?
[01:07] <dtchen_> it's only a one-time hit (I think), so I could live with it
[01:07] <ScottK> Personally I like keeping a clear separation between what I've done and what's upstream
[01:08] <maco> we have 10Mbps internet at home
[01:08] <dtchen_> maco: work sites don't generally give unfettered access anywhere
[01:08] <cody-somerville> I used to have 25mbps but I recently moved and now have 4mbps
[01:08] <cody-somerville> : (
[01:08]  * StevenK suggests cody-somerville try Australia
[01:09] <maco> ScottK: i think part of the point is that not everything's in debian/patches/ so this way you can merge the patches that are applied directly to the packages more easily
[01:09] <ajmitch> StevenK: You're cruel
[01:09] <maco> from what i hear about internet access, australia is in wales
[01:09] <ScottK> maco: For some version of easily, sure
[01:09]  * TheMuso had to convert a bzr branch to using the debian vcs-imports branch + Ubuntu  yesterday, due to the debian package no longer using patches, and the bzr branch for Ubuntu only containing the debian dir.
[01:09] <StevenK> ... We speak in Welsh?
[01:09] <TheMuso> lol
[01:10] <maco> StevenK: even welsh people dont speak welsh
[01:10] <kklimonda> TheMuso: interesting - so they are using a branch for debian/ and apply patches directly to source?
[01:10] <StevenK> maco: That's because it requires physically tying your tongue into 3 knots
[01:10] <maco> StevenK: i can speak a >tiny< bit of welsh :P
[01:10] <TheMuso> kklimonda: They are using git, and import upstream git into their branch, and apply their changes as git commits, even to files that are part of the upstream code.
[01:11] <StevenK> maco: Yes, that's the tiny bit that doesn't. :-P
[01:11] <maco> StevenK: ive forgotten most of that tiny bit, but i can still make the sounds :P
[01:11] <TheMuso> kklimonda: So those changes then up in the .diff.gz.
[01:11] <kklimonda> TheMuso: nice - which package is that?
[01:11] <TheMuso> kklimonda: libcanberra
[01:11] <ajmitch> TheMuso: it does make sense to not duplicate a vcs as a patch system
[01:11] <ScottK> That's increasingly common
[01:11] <cody-somerville> is that the future?
[01:11]  * kklimonda hopes so
[01:12] <TheMuso> ajmitch: I agree.
[01:12] <ScottK> ajmitch: Also makes maintenance work without access to the VCS pretty impossible.
[01:12] <ajmitch> though it's fairly common still to have the whole package in git/bzr/something else & still have debian/patches
[01:12] <ebroder> Ugh - I hope we get v3 source packages if that's the future
[01:12] <TheMuso> ajmitch: As long as those changes are in individual commits, so one can pull/pick/revert as needed.
[01:12] <cody-somerville> I doubt that'll happen for long
[01:12] <TheMuso> ajmitch: I have seen where a package has been moved into git, and changes done in .diff.gz to the upstrea msource are not in individual commits.
[01:13] <ajmitch> that makes it just painful
[01:13] <ScottK> Personally I think this entire move a VCS thing is great for people who do this every day, but will significantly increase the learning curve for new people.
[01:13] <TheMuso> ajmitch: Yes, thats why I pointed that out. :)
[01:13]  * ebroder agrees with ScottK
[01:13] <TheMuso> ScottK: Yeah I would agree with that.
[01:13] <dtchen_> a VCS with frikkin laser beams would be nice.
[01:13] <ajmitch> usually the source package won't carry the .git or .bzr dirs though
[01:13] <ScottK> Same thing with the push to Quilt as the one true patching system
[01:13]  * cody-somerville likes quilt.
[01:14] <TheMuso> See that is where a vcs is very useful. No *-edit-patch, or make change, duplicate source, unpack fresh source, etc.
[01:14] <maco> ScottK: see i think "bzr push" is easier than making a debdiff
[01:14] <TheMuso> Just make the change, write a commit message, commit, done.
[01:14] <ScottK> maco: Once you get through all the VCS stuff to that point, sure.
[01:14] <maco> ScottK: bzr branch *wait* *do stuff* bzr commit
[01:15] <dtchen_> TheMuso: 0.9.20 ready to go in lp:~crimsun/pulseaudio/lucid
[01:15] <ScottK> "Oh, you want to contribute to Ubuntu, first you have to learn this new VCS that is used almost nowhere else"
[01:15] <TheMuso> dtchen_: Ok thanks.
[01:15] <kklimonda> what is the workflow for keeping full source tree + debian/ in the same branch? we checkout tagged release from vcs, apply cherrypicked patches from master branch and then release? what about VCSes which you can't easily import from?
[01:15] <cody-somerville> I prefer having discrete sets of changes instead of snapshots over time.
[01:15] <StevenK> ScottK: And the fact that you mostly treat bzr like svn is just papered over?
[01:16] <StevenK> Because that weakens your argument, so therefore it must not be important.
[01:16] <maco> bzr and hg basic commands are exactly the same
[01:16] <maco> git is mostly close too..clone v. branch is the difference
[01:16] <ScottK> StevenK: For someone who has svn experience it's not so bad, but it's still an increase in the barrier to contribution.
[01:16] <ajmitch> contributing to ubuntu or debian requires plenty of esoteric knowledge as it is
[01:17] <maco> (note: *only* for basic commands. git gets insane)
[01:17] <ajmitch> it's yet to be seen whether having everything in branches will simplify it or not
[01:17] <StevenK> maco: clone is about the only git command I know
[01:17] <ebroder> ajmitch: Doesn't mean we should make it worse
[01:17] <dtchen_> s/insane/usable for a select workflow or way of thinking/
[01:17] <maco> StevenK: commit and push are the same
[01:17] <maco> StevenK: oh, pull too
[01:17] <StevenK> dtchen_: s/$/If you're very lucky, or Linus/
[01:17] <ajmitch> ebroder: I'm undecided whether it's making it worse or not
[01:18] <maco> StevenK++
[01:18] <ScottK> I think it's better, just harder.
[01:18] <cody-somerville> atleast we're not using git, then it would be worse and harder!
[01:18] <StevenK> But faster!
[01:18] <maco> yes
[01:18] <cody-somerville> StevenK, for small values of fast only
[01:18] <TheMuso> Speaking of Australia, I now start the big gamble that is applying for ADSL on a newly activated/connected phone line in a apartment. :)
[01:18] <dtchen_> which is well, kinda useful when pulling down hundreds of megs.
[01:19] <StevenK> I find git slower, in that it takes me 4 times longer to figure out how to do something in git that I can just do off the top of my head in bzr/svn.
[01:19] <cody-somerville> +1
[01:19] <ebroder> StevenK: That's perception bias. I'm exactly the other way around
[01:19] <chrisccoulson> heh, i find git quite hard too. it's a shame that gnome uses it now
[01:19] <cody-somerville> I'm sure if I knew how to use git I'd love how powerful and robust it is
[01:19] <StevenK> ebroder: You didn't use svn much?
[01:19] <dtchen_> ScottK: perhaps if there solid guis for bzr, the barrier may be a bit lower than you're suggesting?
[01:20] <dtchen_> there are*
[01:20] <ebroder> StevenK: I use git for almost everything, and git-svn where I can't
[01:20] <ScottK> dtchen_: It's been a while since I looked.
[01:20] <RAOF> chrisccoulson: I have to say that my interaction with git.gnome.org is entirely through bzr.
[01:20] <StevenK> ebroder: Well, then of course you're biased towards git.
[01:20] <dtchen_> I admit I haven't actually tried editing sound/pci/* in, say, Eclipse
[01:21] <chrisccoulson> RAOF - you can't commit to git.gnome.org that way though can you?
[01:21] <cody-somerville> http://doc.bazaar-vcs.org/migration/en/_images/welcome-new-project.png <-- I think bzr does have a nice gui now.
[01:21] <TheMuso> dtchen_: Would you want to? :)
[01:21] <kklimonda> RAOF: how well does it work? using bzr to interact with git repositories?
[01:21] <ebroder> StevenK: I think the point is that it's entirely a matter of what you're used to
[01:21] <cody-somerville> chrisccoulson, I think you can
[01:21] <RAOF> chrisccoulson: You could.  I don't have commit access to anything, but you certainly can.
[01:22] <chrisccoulson> ah, i didn't know that
[01:22] <ebroder> StevenK: I know people who used RCS but not svn and found git more intuitive than svn
[01:22] <chrisccoulson> i'll have to try that next time i commit something
[01:22] <StevenK> Yes, but RCS is .... awful
[01:22]  * StevenK had to try multiple times to not using a curse word for that sentence
[01:22] <cody-somerville> hmmm... the help file for git log is 26 pages long. :/
[01:23] <RAOF> chrisccoulson: AFAIK there isn't any way to specify a git branch that isn't master, but that might have changed.  That's, I think, the last big hole.
[01:23] <chrisccoulson> i wasn't aware of that - thanks!
[01:23] <TheMuso> RAOF: In what context are you referring to when you talk about specifying branches?
[01:23] <chrisccoulson> although, i don't commit to git.gnome.org all that often
[01:24] <maco> cody-somerville: wow
[01:24] <RAOF> TheMuso: The git context.  As in: I'd like to bzr branch this particular branch of a git repository, do some hacking, and then push back to the git branch.
[01:26] <TheMuso> RAOF: Right, I think when you clone a repo, it clones all branches. You then have to set up a local branch to track a remote branch, make your changes, and then push back to the remote repo specifying the branch you want to push to.
[01:26] <TheMuso> Complicated to explain in a few words.
[01:26] <RAOF> TheMuso: Oh, no.  I know how to do it with git, but you can't do it with bzr-git.
[01:26] <RAOF> Sorry, that was obviously less than well-explained.
[01:26] <TheMuso> RAOF: Oh right.
[01:26] <ajmitch> I think it's complicated because bzr & git have slightly different views of branches & repositories, from what I've seen
[01:26] <dtchen_> ajmitch: I think so, too
[01:27] <RAOF> It is, yes.
[01:29] <RAOF> It wouldn't be impossible to add a new branchspec that understood how to get a particular branch from a git repository, though.  At least, in my limited understanding.
[01:45] <LaserJock> kirkland: just read your blog post on testdrive but I'm a little uncertain of what it actually does. Does it just download the .iso and fire it up in KVM/VirtualBox?
[01:46] <kirkland> LaserJock: basically, yes
[01:46] <kirkland> LaserJock: where "download" =~ tries to incrementally sync it
[01:46] <kirkland> LaserJock: such that it'll be useful with daily iso's, once Lucid starts publishing dailies
[01:47] <LaserJock> hmm, but doesn't a simple zsync command do the same thing?
[01:47] <ajmitch> it sounds basic but useful
[01:47] <kirkland> LaserJock: yes, it use rsync || zync || wget
[01:47] <LaserJock> did it come from the downloader that the QA team has?
[01:48] <kirkland> LaserJock: no
[01:50] <kirkland> LaserJock: what downloader is that?
[01:51] <LaserJock> dl-ubuntu-test-iso
[01:51] <LaserJock> it's in ubuntu-qa-tools
[01:51] <LaserJock> it uses zsync, rsync, or wget I think
[01:51] <LaserJock> you tell it what arch/flavor, etc. and it grabs the .iso
[01:53] <LaserJock> the man page is mostly rsync but I know they added zsync later in Karmic
[02:17] <maco> LaserJock: dude thats awesome
[02:17] <LaserJock> maco: what is?
[02:17] <maco> LaserJock: what you said about dl-ubuntu-test-iso
[02:17] <maco> i had no idea that existed
[02:23] <chrisccoulson> has anyone noticed recently an increase in the number of users who just come and randomly change bug states without any comment?
[02:24] <ScottK> chrisccoulson: Yes.  It's thanks to the ajaxification of that in Launchpad.
[02:24] <ScottK> It's now very easy to do.  In fact it's encouraged by the design.
[02:24] <sbeattie> maco|LaserJock: fair warning, zsync has problems handling files > 2GB on 32bit platforms; there's an SRU for karmic that addresses it.
[02:25] <maco> the isos arent that big...
[02:25] <ScottK> DVD ones are
[02:25] <maco> ah yeah
[02:25] <chrisccoulson> ScottK - you're probably right. i wasn't sure whether users were doing it accidentally, or doing it just to be disruptive
[02:26] <ScottK> chrisccoulson: Not sure.  I think it's mostly a combination of accidents and not realizing they should make a comment.
[02:26] <ScottK> IIRC, Ubuntu people asked Launchpad people to have the change reverted and got told no.
[02:27] <chrisccoulson> it is quite annoying to have to revert changes nearly every day now :-/
[02:28] <ScottK> Well IMO Launchpad and quite annoying are frequent associates.
[02:29] <chrisccoulson> heh
[02:29] <chrisccoulson> i had to delete 600 mails from one bug from my inbox today
[02:30] <chrisccoulson> it's quite annoying when getting spammed each time the retracer finds another duplicate of a popular bug
[02:31] <ajmitch> how many extra mails do you get from people wanting to unsubscribe from that bug?
[02:33] <chrisccoulson> the seahorse-plugins bug? quite a few people asked for instructions to unsubscribe, and there were also a lot of people posting instructions, and some people clearly confused about why they were getting so many mails
[02:34] <chrisccoulson> it's a shame we can't view the bug in launchpad any more, because i've fixed it in karmic-proposed, and could do with getting feedback from users with the normal SRU process
[02:34] <chrisccoulson> that's difficult at the moment though
[02:34] <kklimonda> chrisccoulson: you have fixed it? my hero :)
[02:34] <chrisccoulson> kklimonda - yep, it's fixed, if you want to test it ;)
[02:34]  * kklimonda got tired of getting ~80 mails every day ;)
[02:35] <ScottK> It's even better when you're getting the bug mail because a team is subscribed to the package or because you're subscribed teo the package bugs.  Basically you can't unsubscribe.
[02:35] <chrisccoulson> that's a pain. fortunately, i'm not subscribed to many teams which get bug mail
[02:35] <chrisccoulson> i suspect you probably see significantly more bug mail than me ;)
[02:36]  * ScottK has seen bug mail where people were begging to make it stop.
[02:36] <kklimonda> chrisccoulson: you can easily fix that and subscribe to desktop-bugs ;)
[02:36] <kklimonda> ScottK: ya, I've seen that too with seahorse-plugins bug..
[02:36] <ScottK> Usually when a bug affected multiple packages and the one package they cared about was long fixed
[02:38] <LaserJock> ScottK: yeah, well I lost a  whole team to that
[02:38] <chrisccoulson> in some cases, it would be useful to be automatically subscribed to bugs for a particular package for a couple of weeks after doing an upload
[02:38] <LaserJock> ScottK: I had collected a group of Debian developers and then they all left after the 3rd or 4th bugmail storm
[02:39] <StevenK> Ha. Lightweights.
[02:39] <ScottK> LaserJock: I believe it.
[02:39] <StevenK> Were none of them subscribed to debian-devel?
[02:39] <LaserJock> I believe they might have been
[02:39] <StevenK> Then they really are.
[02:39] <LaserJock> we got ~ 100 emails in about 1 hr
[02:39] <StevenK> Or they need to filter e-mail better
[02:40] <ScottK> The translation template mails are even less use and more annoying from my perspective.
[02:40] <StevenK> Oh, agreed
[02:40] <LaserJock> what's frustrating is even if you mark your task Invalid you still get flooded
[02:40] <StevenK> Why must I get a whole bunch of useless mail when I upload something?
[02:41] <ScottK> StevenK: Because we use Launchpad.  What more do you need to know.
[02:41] <ajmitch> this is why most of my bug mail goes into a large folder & I just use mutt searches to narrow down the flood
[02:41] <ajmitch> ScottK: it's free software now, go fix it that way -->
[02:41] <StevenK> Haha!
[02:41]  * ebroder <3 Gmail's search
[02:42] <StevenK> ajmitch 1, ScottK 0
[02:42] <ScottK> Last time I asked, the response was something like "but someome might want them", IIRC
[02:42] <StevenK> ScottK: So? Submit a branch, that makes it slightly harder to say no.
[02:42] <ScottK> ajmitch: I don't have commit rights.  This isn't a bug, it's the design
[02:43] <StevenK> ScottK: I'm curious why that's a problem.
[02:43] <ScottK> StevenK: I don't think my blood pressure could take it.
[02:43] <ScottK> Back in 5 ...
[02:43] <ScottK> StevenK: Why what's a problem?
[02:43] <StevenK> ScottK: Why is you not having commit access a problem?
[02:44] <LaserJock> because it has to be OK'd
[02:44] <ajmitch> noone has commit access, really, since all branches get reviewed
[02:44] <LaserJock> therefore get's checked against "we designed it that way"
[02:46] <ScottK> LaserJock: Exactly
[02:46] <StevenK> So? That's a feature
[02:46] <ScottK> So "It's Free Software" only helps in the case of accidental problems, not the on purpose kind
[02:47] <StevenK> The barrier of entry is higher than you percieve it
[02:47] <cody-somerville> lol
[02:47] <ajmitch> like any free software program, you have to argue for design changes
[02:47] <StevenK> This is sounding more and more like "Oh, that sounds like real work. Oh well, I'll just complain about it, and hopefully annoy someone else into fixing it."
[02:48] <ScottK> No, it's I've talked to the developers about it and they think it's fine the way it is and don't intend to change it.
[02:48] <ScottK> It's possible they changed their minds or I misremember.
[02:49] <StevenK> I suggest subscribing a developer to a team that gets bug stormed and then see what happens. :-)
[02:49] <StevenK> That strikes me as somewhat cruel.
[02:49] <ajmitch> Sometimes you must be cruel to be kind, right?
[02:49] <ScottK> In the right measure, yes.
[02:50] <StevenK> But surely you can fix the team so that bug mail gets sent to a list
[02:51] <StevenK> If you don't want to get stormed, unsubscribe from the list
[02:51] <LaserJock> and you miss the bugmail
[02:51] <zul> procmail usually helps as well
[02:51] <StevenK> Well, sure, but there's no magical button in Launchpad to say "only mail me the bugs that look like they may interest me"
[02:52] <LaserJock> no
[02:52] <LaserJock> but you should at least be able to unsubscribe
[02:52] <LaserJock> which is all I asked for like 2 years ago
[02:52] <StevenK> And you miss the bugmail
[02:52] <StevenK> To use your own argument against you
[02:52] <LaserJock> but you made that choice
[02:52] <LaserJock> for the particular bug
[02:53] <ScottK> The explicitly unsubscribe to a bug you've been implicitly subscribed to is an open bug
[02:53] <StevenK> I thought you could do that?
[02:53] <ScottK> The "it's that way one purpose" was about the translations email.
[02:53] <StevenK> ScottK: Oh, that's easy to fix. Get one of the launchpad guys to sponsor an openoffice.org upload
[02:53] <LaserJock> StevenK: perhaps that's been fixed "recently" but my team is long gone
[02:55] <ScottK> Just checked.  No unsubscribe button for a bug that I'm subscribed to the package for
[02:55] <ScottK> LaserJock: Not fixed AFAICT
[02:57] <jml> ScottK, https://bugs.edge.launchpad.net/malone/+bug/412925 fwiw
[02:57] <ScottK> jml: That's the one.
[02:57] <ebroder> maco: Looks like you ended up with a bunch of extra autoconf/manpages stuff in the latest debdiff for 415766
[02:57] <jml> ScottK, I haven't spoken with the malone team recently, but I think they agree that something needs to change.
[02:58] <maco> ebroder: oh boo now whyd it do that
[02:58] <jml> I'm confident that they'd be happy to help someone prepare a patch :)
[02:58] <maco> ebroder: can i just manually mangle the old debdiff? would anyone care?
[02:58] <ebroder> maco: I've caught the clean stage of the openafs package doing that before. Don't remember why off the top of my head
[02:58] <ebroder> maco: Yeah, that's totally fair
[02:59] <ScottK> jml: I last saw the bug after it was wontfixed.
[02:59] <nixternal> just ignore the bug reports, that's what I do...now anything with the word 'BUG' gets sent straight to [GMail].Spam ;p
[03:00] <maco> ebroder: sent
[03:00] <nixternal> and then in a year, when I feel like fixing bugs, do a "Oh, I apologize for not responding sooner to this report, here is a piece of chocolate"
[03:01] <LaserJock> I've just been using the package report pages
[03:01] <LaserJock> and pretty much ignore bugmail
[03:02] <ebroder> maco: I think the version should be 1.4.11+dfsg-1+ubuntu0.1 - that's what I've used for openafs SRUs in the past
[03:03] <maco> ebroder: oh right cuz debian is -1....wah thats confusing
[03:03] <ebroder> Yeah...
[03:03] <maco> ebroder: this pkg has truly fubar versioning
[03:03] <ScottK> ebroder: Without the "+"
[03:03] <ScottK> 1ubuntu0.1
[03:03] <ebroder> ScottK: No, you need the +, otherwise it screws up modules built by module-assistant
[03:03] <ScottK> Oh.
[03:04] <ScottK> Nevermind
[03:04] <maco> right this is why we're sitting here mucking with version strings
[03:04] <maco> because 1ubuntu0.1 is what i uploaded before
[03:04]  * ScottK nods
[03:06] <ebroder> One of these days when I'm feeling particularly masochistic, I may write up a proposal for Ubuntu to use N+ubuntuM instead of NubuntuM. Debian uses this for their stable release updates these days
[03:06] <ebroder> c.f. libcups2 1.3.8-1+lenny7
[03:08] <maco> ebroder: ok NOW is it ok?
[03:08] <ebroder> maco: I'll let you know when it makes it to LP
[03:10] <ScottK> ebroder: Because our revision numbers aren't long enough already?
[03:10] <ebroder> ScottK: Becuase if Ubuntu was consistent about it I wouldn't have to argue about the + every time I want to upload to openafs :)
[03:10] <ebroder> maco: Looks perfect - thanks
[03:12] <maco> wow...you mean we could have libcups2-1.3.8-1+lenny7+ubuntu1?
[03:12]  * StevenK twitces
[03:12] <StevenK> *twitches
[03:12] <ebroder> Well, we don't sync from post-release Lenny updates
[03:12] <StevenK> That isn't a sync
[03:12] <StevenK> And we can merge from wherever we want, if we so wish to
[03:15] <jdong> maco: *SLAP*
[03:15] <jdong> AARRRRRRGH
[03:15] <maco> jdong: ebroder made me do it!
[03:15] <jdong> maco: didn't we have this discussion about hand-editing patches?
[03:15] <maco> jdong: i didnt touch the patchy part or add new lines!
[03:15] <maco> oh.
[03:16] <maco> wait...this is that one that i hand-edited before
[03:16] <maco> slightly more hand-edited but without new lines this time
[03:16] <jdong> :)
[03:16] <maco> he said it was ok *points to ebroder*
[03:16] <ajmitch> maco: where's the +isreally+1.2.6 part that it needs? :)
[03:17] <ebroder> I <3 that in version numbers
[03:17] <maco> jdong: you're going to give me noogies if we ever meet, arent you?
[03:18] <jdong> lol
[03:18] <jdong> don't worry
[03:18] <jdong> I still love you ;-)
[03:19] <StevenK> Be warned that jdong considers noogies a form of affection
[03:21] <maco> great so StevenK's going to tickle me for making fun of his accent and jdong's gonna give me noogies...
[03:22] <StevenK> Sounds like fun.
[03:22] <StevenK> jdong and I should make sure to do it at the same time, too
[03:22]  * ajmitch would be worried about that
[03:22] <maco> hahaha
[03:22] <maco> sounds like i need a corset and a helmet
[03:22] <StevenK> Oh, a corset won't stop tickling
[03:23] <maco> you cant tickle through a corset
[03:23] <ajmitch> something like an electric cattle prod would help keep them off
[03:23] <ScottK> It's Texas.  Firearms are legal.
[03:23] <maco> i know, the ubuntu women team is organizing a trip to the shooting range
[03:23] <maco> for uds
[03:24] <StevenK> maco: They aren't that thick, and they're skin-tight, so it should be possible ...
[03:24] <jdong> WHAT ON EARTH IS GOING ON?
[03:24] <ajmitch> jdong: madness
[03:24] <maco> high levels of silly
[03:27] <ScottK> It says something when jdong is the stable, level headed one in the room.
[03:27] <ajmitch> heh
[03:27] <ajmitch> very much so :)
[03:30] <LaserJock> maco: oh man, you're going to go shooting? I'm envious. I had to leave all my weaponry in MT when I moved to Boston
[03:30] <maco> LaserJock: *i'm* not going shooting. akgraner is, and czajkowski's like "you have guns in your country? i wanna try!"
[03:31] <ScottK> maco: Why aren't you going?
[03:31] <maco> eek! guns!
[03:31] <maco> now if they were going to the *archery* range..
[03:32] <LaserJock> maco: well, they're similar, just one goes a little faster and has a bit more bang to it ;-)
[03:33]  * TheMuso reads backscroll and can't stop laughing.
[03:34] <ajmitch> LaserJock: similar in a vague sort of way...
[03:35] <LaserJock> ajmitch: well, I've killed things with both, the effect is similar
[03:36] <ScottK> :-)
[03:36] <LaserJock> although I am always amazed when I have friends try a pistol/rifle for the first time
[03:36] <LaserJock> apparently it's not exactly how it looks on TV
[03:37] <ajmitch> now that's a surprise :)
[03:40] <StevenK> Haha, yes
[03:40] <StevenK> "Um, I just fired this rifle, and now I'm on the ground."
[03:43]  * TheMuso would be frightened of both the recoil and the bullet.
[04:00] <jdong> maco: poke poke
[04:00] <jdong> are you regenning the patch?
[04:02] <maco> am now. but before it spewed weird autoconf stuff into it when i tried
[04:03] <ebroder> Try...doing a debuild clean before you do the debuild -S or something?
[04:04] <maco> jdong: ok ther
[04:05] <maco> ebroder: it worked this time *shrug*
[04:05]  * ebroder shrugs. That doesn't surprise me too much
[04:06] <jdong> someone play refresh timer for me.
[04:09] <jdong> maco / ebroder : uploaded
[04:09] <ebroder> Yay :)
[04:10] <maco> yay
[05:14] <Hemidrone> My love goes out to these people. I sync my datas, set up vpns, play with my MP5's. Truely sexxi!!! -> http://mange.dynalias.org/linux.html
[05:17] <Hemidrone> Hmm, why are there always brown wimen on the music channels ? ... I dont dislike them, but we also pay so i think a few white wimen could also be nice to watch.
[05:20] <Hemidrone> Yeesh! Looks ugly when brown wimen wants to look whiter using some lenses and video lenses etc. Now, i have some brown friends and i like those.
[05:20] <Hobbsee> Hemidrone: i don't think you really want to continue...
[05:20] <Hemidrone> Korean wimen are very sexxi.
[05:21] <ScottK> Thanks.
[05:35] <mneptok> is the speed of -server sessions being added to the UDS schedule affected by my use of the refresh icon?
[06:24] <Ademan> does upstart set variables that are used in upstart scripts? for instance the gdm upstart script uses $CONFIG_FILE which isn't set anywhere in the script that i can see.
[06:31] <cody-somerville> Ademan, no, I don't think so
[06:32] <cody-somerville> Ademan, and looking at gdm-binary --help, it doesn't look like it accept a config file as an argument.
[06:32] <pitti> Good morning
[06:32] <pitti> lamont: yes, that was lucid
[06:54] <dholbach> buon giorno!
[06:55] <Ademan> cody-somerville: so you think the upstart script is bogus?
[07:42] <bossekr> hi all; within the last two days I tried to use the edit@bugs.launchpad.net email interface to change bugs in Ubuntu as Debian developer for "my" package but nothing happens
[07:43] <maco> bossekr: replace "edit" with the bug number
[07:43] <bossekr> hmm, the edit@ interface for multiple bugs and this is what I've done
[07:44] <bossekr> there are a bunch of bugs to change
[07:44] <maco> ah ok
[08:07] <siretart`> morning
[08:08] <siretart`> pitti: just to be sure, we don't allow GPLv2 licensed applications to link against MPL licensed libraries in ubuntu. is this correct?
[08:08] <pitti> siretart`: hm, can't say offhand; was it handled like that so far?
[08:09] <siretart`> I'm not sure if the current case I'm looking at is deliberate or a mistake.
[08:09] <siretart`> in fact, its the only divergence we currently carry from debian. I suspect we imported the package from debian and then the package was changed
[08:16] <siretart`> filed as bug #481789
[08:40] <pitti> james_w: do you know if there's any way to suppress the millions of "branch linked" LP mails which hit my mailbox every day?
[08:44] <maco> pitti: the openafs one that was in proposed was -1ubuntu0.1 this is -1+ubuntu0.1 because module-assistant gets stupid without the +
[08:44] <pitti> maco: oh, sorry; will reprocess then; so that was the only change, right?
[08:44] <maco> yeah
[08:44] <maco> just a bumped version number to make m-a happy
[08:47] <pitti> done
[08:49] <maco> pitti: thanks
[09:04] <pitti> maco: ooh, congrats to your new MOTU badge!
[09:04] <Tm_T> another lost soul...
[10:36] <ashiswin> ls
[11:00] <ashiswin> umm
[11:00] <ashiswin> could anyone tell me how to develop for ubuntu
[11:00] <ashiswin> i do C java C++
[11:01] <ashiswin> stuff like that
[11:01] <ashiswin> so any help?
[11:02] <azeem> #ubuntu-motu is for getting involved with Ubuntu development
[11:02] <azeem> as for development *on* Ubuntu, that is off-topic here
[11:06] <\sh> moins
[12:18] <Keybuk> mvo: that's how I want to do fsck forcing eventually yeah :)
[12:19] <mvo> Keybuk: cool, thanks
[13:04] <primes2h> apw: Hello, Could you have a look at this please? bug #374459 . It has already a commit from upstream ready to apply.
[13:04] <lamont> pitti: 127.0.1.1       invalid <-- should fix it, yes?
[13:05] <lamont> hrm... ah.
[13:05] <pitti> lamont: 'invalid'?
[13:05] <pitti> lamont: oh, you mean "you should fix it", not "this should fix it" :)
[13:05] <lamont> yeah - that's the host name
[13:06] <lamont> but that's not how I fixed it before and so yeah... let me see about smacking it over the head harder...
[13:10] <apw> primes2h, that should be fixed in karmic right?
[13:14] <primes2h> apw: it's not fixed yet. It's fixed upstream, here you find the info about the commit that fixes it http://bugzilla.kernel.org/show_bug.cgi?id=13363
[13:14] <apw> primes2h, which is false as the commit upstream is already in the release karmic kernel and not fixing you, correct?
[13:17] <apw> i've added that info to the bug, and asked for testing and collection of some more information
[13:19] <primes2h> apw: I'm not sure that the commit is already in karmic kernel, because the bug is present :) and because of this comment https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/374459/comments/44
[13:19] <apw> primes2h, i am cirtain that the fix is in the karmic kernel, i just checked.  but the fix is model specific
[13:19] <apw> so your model is not _exactly_ the same one then the fix will not trigger
[13:20] <primes2h> apw: ah, ok.
[13:20] <apw> hense the request for testing and on failure the attach of dmidecode output
[13:20] <primes2h> apw: by the way, I can't use the  workaround described because it applies to grub, not to grub2
[13:21] <primes2h> apw: I mean this kernel option i8042.nomux=1
[13:21] <apw> you can add kernel options in both?
[13:21] <primes2h> apw: (I have to learn hot grub2 works)
[13:21] <primes2h> :)
[13:23] <apw> it may be GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub that sets it
[13:23] <apw> then run update-grub
[13:25] <primes2h> apw: Is it safe to add a line by hand in /etc/default/grub. It's advised against doing it.
[13:25] <primes2h> ?
[13:25] <primes2h> grub?
[13:26] <apw> /boot/grub* is normally replaced and you lose your changes
[13:26] <apw> i _though_ /etc/default/grub was the right place, but i can't say i know for sure
[13:27] <primes2h> apw: BTW, I already did an apport-collect about linux package in the bug report. Is it enough?
[13:28] <apw> the important thing is that the dev trying to fix it knows which dmi-decode and which model name and which 'does not work with latest karmic' go together
[13:28] <apw> so i would put the dmi-decode output on an attachment to the update which says your model isn't working
[13:28] <primes2h> apw: Does I need just to launch dmidecode in a terminal?
[13:28] <apw> that makes out job simpler, as we cannot get things mixed up
[13:29] <apw> probabally sudo dmidecode in a terminal yes
[13:29] <primes2h> apw: Yes ;)
[13:29] <primes2h> I meant that
[13:29] <lamont> pitti: if you would be so kind as to reupload cups with the test suite back on?  should build now.  Assuming so, could you migrate the bug to launchpad-buildd by whatever means makes the most sense - lp-buildd should be fixing the hostname in the chroot, rather than the hack we have to resolve invalid
[13:29] <pitti> lamont: \o/ thanks muchly, reuploading
[13:32] <pitti> lamont: the bug is already assigned to launchpad-buildd project -- that isn't right?
[13:33] <lamont> absolutely correct.
[13:34] <lamont> color me illiterate
[14:16] <helger> Anyone know Where can I report a bug in Ubuntu One
[14:16] <helger> ?
[14:26] <primes2h> apw: Done. I added dmidecode output into the bug report. Thank you very much.
[15:25] <pitti> lamont: hm, failed again :-(
[15:33] <lamont> pitti: gar
[15:33] <lamont> what exactly is the hostname it looks up, I wonder?
[15:34] <StevenK> lamont: Surely there is no hostname resolution on the buildds, though?
[15:34] <lamont> StevenK: well... they can resolve things like 'archive.ubuntu.com' :-)
[15:34] <lamont> random hostnames? no.
[15:35] <StevenK> *cough* ftpmaster.internal :-P
[15:35] <chrisccoulson> congrats maco!
[15:35] <StevenK> But yes, I was meaning random hostnames
[15:35] <pitti> lamont: I thought just the local host name, let me check the code
[15:35] <lamont> StevenK: we broke that semi-recently, it used to be able to resolve, but not to contact
[15:36] <maco> chrisccoulson: thank ya
[15:36] <pitti> lamont: "vernadsky"
[15:37] <lamont> pitti: and WTF does it look up that host name?
[15:37] <StevenK> lamont: I thought that is were Build-Depends downloaded from? :-)
[15:37] <pitti> lamont: it's what httpGetHostname() determined
[15:37] <StevenK> pitti: Does it use gethostbyname() or a custom resolver?
[15:38] <lamont> StevenK: I meant resolving random hostnames
[15:38] <StevenK> lamont: Oh, right
[15:38] <pitti> lamont: http://paste.ubuntu.com/317888/
[15:38] <StevenK> lamont: My context switching is broken
[15:38] <pitti> lamont: gethostname()
[15:38] <pitti> lamont: but "vernadsky" sounds correct for the buildd?
[15:39] <lamont> pitti: 'vernadsky' is a buildd, yes
[15:39] <lamont> and (intentionally) the search list in resolv.conf lacks 'buildd', and vernadsky.canonical.com is NXDOMAIN
[15:39] <pitti> lamont: hm, it worked until some weeks before karmic; any idea what changed at that time?
[15:40] <StevenK> But vernadsky.buildd should surely be in /etc/hosts?
[15:40] <StevenK> It's using gethostbyname(), so /etc/hosts should certainly be checked
[15:40] <lamont> hostname; hostname --fqdn
[15:40] <lamont> king
[15:40] <lamont> hostname: Unknown host
[15:40] <pitti> so it uses gethostname(), and if that isn't a FQDN, uses gethostbyname() (but if that returns NULL, it doesn't bother)
[15:41] <lamont> StevenK: that would surely be the point of the bug
[15:41] <pitti> so AFAICS, if it can resolve "vernadsky", it should suffice
[15:41] <lamont> StevenK: /etc/hosts used to contain an entry for whatever host built the image.
[15:41] <lamont> and the search list had buildd in it
[15:44] <lamont> pitti: what you're actually saying is "please add buildd back to the search list", or "please make /etc/hostname contain the fqdn for the host on all of the buildds"
[15:45] <lamont> though I suppose that testing network connectivity for cups might entail using a hostname
[15:46] <lamont> pitti: as for why it broke, the chroots were changed to not have buildd in the search list
[15:47] <pitti> ah, I see
[15:47] <lamont> and ultimately, the fix is to have a hosts file entry, written by lp-buildd as part of unpacking the chroot
[15:48] <pitti> how wonderful .. all those days it's nice in Dallas except for next Sunday, when we have our only day off :)
[15:48] <StevenK> Ah yes, since you don't want to do that for the chroots themselves
[15:49] <serialorder> not sure if this is the right channel but I am getting the following error: Gtk-Message: Failed to load module "canberra-gtk-module": libcanberra-gtk-module.so: cannot open shared object file: No such file or directory
[15:49] <serialorder> and I am trying to find out where it is coming from
[15:57] <lamont> pitti: so the long and the short is that un-hacking cups is easiest described as "blocked by this here lp-buildd bug"
[15:58] <lamont> :-(
[16:16] <amichair> mvo: I made a bunch of fixes on software-properties-kde... are u the man to talk to about reviewing/merging?
[16:18] <Riddell> amichair: actually glatzor might be more a candidate for that
[16:18] <Riddell> amichair: and of course I can do it too, just a bit busy with preparing for UDS right now I'm afraid
[16:19] <Martyn> Same here.
[16:19] <amichair> Riddell: I noticed u and apachelogger seem very busy... trying to find someone else to bug :-)
[16:19] <Martyn> And gobby seems to be down
[16:19] <Martyn> PLUS the topic script on the UDS site is also really broken
[16:20] <Martyn> If you go to any given day on the schedule, you can clearly see the right things on the right days
[16:20] <Martyn> if you try doing it by topic (server, mobile, etc) it all gets stuffed between 14:00 and 15:00
[16:44] <kees> good morning!
[16:45] <kees> zul: btw, I've noticed in security updates that cyrus-sasl2 and cyrus-sasl2-heimdal have to be the same version.  when you sync one, can you bring in the other too?
[16:47] <zul> kees: sure
[17:37] <pitti> slangasek: hm, the samba karmic-proposed SRU has a lot of new files (source3/exports/libsmbclient.syms, source3/exports/libsmbsharemodes.syms, source3/lib/netapi/tests/Makefile, etc.); was that intentional?
[17:42] <mvo> amichair: hey! yeah, I'm the one for the merge, what is the branch name?
[18:33] <bdmurray> pitti: Do you think bug 455740 needs a karmic task?
[18:38]  * mpt_ wonders how the Ubuntu Software Center could tell that package Y is an add-on for package X
[18:39] <mpt_> e.g. that adblock-plus is an add-on for firefox-3.5
[18:39] <StevenK> mpt_: Sounds like a use-case for Enhances
[18:39] <mpt_> Does Enhances exist?
[18:39] <StevenK> Certainly does
[18:39] <mpt_> cool
[18:39] <mpt_> oh, of course it does, it's in the window I'm staring at right now
[18:39] <mpt_> nifty nifty nifty
[18:39] <StevenK> Heh
[18:45] <mpt_> thanks StevenK, I thought I'd get a useful answer in here
[19:09] <amichair> mvo: lp:~amichai2/software-properties/fixes
[19:09] <amichair> mvo: u can ignore the revision with gpg, it is later reverted
[19:10] <amichair> mvo: and being new to python/qt/kde, I'd be happy to get as much feedback as possible :-)
[19:18] <ttx> mneptok: ping
[19:18] <mneptok> ttx: pong
[19:19] <ttx> mneptok: hey -- about the mariadb session for uds
[19:19] <ttx> mneptok: I assume you are willing and able to chair the session ?
[19:20] <mneptok> ttx: sure. happy to do so.
[19:20] <mneptok> ttx: are you working on scheduling by any chance?
[19:20] <ttx> mneptok: yes
[19:20] <mneptok> ttx: if you can schedule it for Monday i can probably get Monty there, as well.
[19:20] <ttx> mneptok: let's see
[19:21] <ttx> mneptok: tricky
[19:21] <mneptok> ttx: just be aware, i work for Monty Program. i'm not a completely disinterested party in this. we'll of course follow what the community wants to do, but in the interest of full disclosure ....
[19:21] <ttx> mneptok: I'll need to move a few slots around
[19:21] <ttx> mneptok: I'll let you know asap
[19:22] <mneptok> ttx: don't jump through too many hoops. having Monty would be great, but i'd rather not do it if it means disruption to other blueprints.
[19:22] <ttx> mneptok: ok
[19:50] <slangasek> pitti: samba karmic-proposed> that's because I always do a debuild -uc -us -b first, and apparently the clean target is insufficient
[21:10] <smoser> slangasek, ping
[21:43] <ebroder> gdm sticks a little Ubuntu logo at the top of the login box - where does that come from? It's not part of ubuntu-xsplash-artwork like the rest of the artwork
[21:46] <mterry> persia, can you add me to ubuntu-universe-sponsors?
[21:47] <Azverkan> Has there been any discussion as to reverting mountall for karmic and pushing it to lucid?  Or releasing a separate alternate karmic installer that doesn't attempt tot use it?
[21:48] <StevenK> Azverkan: Why?
[21:49] <Azverkan> On all the test upgrades I've done it works with varying degrees of success
[21:49] <StevenK> Then file bugs, rather than advocating reverting it?
[21:49] <Azverkan> It seems like the package still has a few months of bugfixing before it could be declared stable
[21:51] <Azverkan> Long term getting the bugs reported and fixed is the best approach, I'm just wondering what to do in the short term as the package renders many configurations unusable
[21:57] <ScottK> AFAIK, the mountall changes are very intertwined with the other boot changes, so you can't really just 'revert mountall'.  It would be the whole boot process.
[21:58] <StevenK> Yeah
[22:01] <mjr> On Dell Latitude E4200 / 9.10 it seems that the (touchpad) mouse is often lost on resume from suspend, though comes back after VC back-and-forth. Known? Should probably report properly?
[22:03] <Azverkan> the new boot process is all event based now, is there a page anywhere that details the best way to debug it?  (I remember all the fun with kernel 2.6.31-rc8 breaking inotify and how nonobvious it was)
[22:45] <slangasek> smoser: might take fewer round-trips if you would say what you need :)
[22:59] <SNLala> hey. google-earth zoomt bei einer suche auf die richtige stelle. aber der "placemark" der gesetzt wird, ist an einer anderen stelle. kennt das auch jemand?
[23:00] <tormod> SNLala, -> #ubuntu-de
[23:00] <SNLala> sry. wrong channel
[23:00] <SNLala> yeah thank you