[00:19] <psusi> god damn I love emacs!
[00:21] <psusi> diff-mode for the winz
[00:26] <psusi> worked up a patch the other day to add an argument to a signal upwer emits over dbus... decided to change it from a string to a uint today... open the quilt patch, scan the lines I changed, tap C-c on each that might need modified to jump to the code, make change if needed, rinse, repeat, finally quilt refresh.  patch converted in under a minute
[01:17] <ScottK> cjwatson: kdm's uploaded.  Thanks for the patch.
[01:18] <bdrung> smoser: i came to an different conclusion for bug #736326 ;)
[01:19] <smoser> bdrung, oh?
[01:20] <psusi> if the current maverick version is 0.9.5-4, then backporting a fix would bump the rev to what?  ubuntu1, or ubuntu0.1?
[01:20] <bdrung> smoser: fix it and make it sound better and then forwarding it
[01:20] <bdrung> psusi: -4ubuntu0.1
[01:21] <psusi> k...
[01:21] <smoser> oh. sorry. i just assumed the bug opener spoke language.
[01:21] <smoser> i do not.
[01:22] <smoser> but yeah, forwarding to debian is correct, definitely. thank you.
[01:22] <bdrung> smoser: his fix was correct. i only improved it further
[01:31] <psusi> reason #768 that quilt patches applied in bzr branches are evil: merge goes all fubar over the .pc stuff
[01:43] <bdrung> psusi: agreed. bzr and quilt are not a good couple
[01:43] <psusi> bdrung, they are a perfectly good couple.. as long as you keep the patches deapplied in the bzr repo
[01:44] <psusi> works great as long as you do that
[01:44] <bdrung> yes, but the package imported commits then applied
[01:44] <ScottK> All the more reason not to bother with UDD.
[01:44] <psusi> yea, that needs fixed...
[01:45] <psusi> half the packages I've been working on lately I guess someone sane manually set up the repo so they are deapplied, and the other half the auto importer imported them applied... bad auto importer
[01:46] <ScottK> Apparently it was thought to be a feature at one point.
[01:46] <ScottK> I think it's not accidental it works that way, but I gather it's being reconsidered.
[01:46]  * psusi takes whoever thought so out behind the tool shed
[01:48] <broder> i still argue that it makes sense given that the resting state of a 3.0 (quilt) package is patches applied. if you don't like what bzr is doing, you really should be taking issue with what the source format is doing
[01:49] <ScottK> I do, but that horse is already out of the barn.
[01:49] <bdrung> broder: it's a pita to look at patches and bzr diffs!
[01:49] <ScottK> The only place I use v3 is where I use it due to orig.tar.bz2.
[01:49] <bdrung> broder: all the changes to files in .pc ...
[01:50] <psusi> broder, say what?
[01:50] <bdrung> ScottK: v3 is cool. you can configure it to apply the patches at the beginning and drop then when finished building
[01:51] <psusi> it is a pita to look at and adds useless bloat to have the quilt patches already applied in the repo
[01:51] <ScottK> bdrung: I think the idea of starting with patches applied is completely backwards.
[01:51] <broder> psusi: i've had this argument with you before, and in the interests of keeping the channel civil, i'm going to pass on having it again at the end of the day on a friday
[01:52]  * psusi can think of few better times to have such an argument ;)
[01:53] <psusi> I'm now reviewing my changes before pushing to lp, and the bzr -p output from the quilt-applied package is 3x larger and nearly unreadable compared to the deapplied one
[01:54] <bdrung> broder: should we file a bug report requesting a change of the importer?
[01:58] <broder> bdrung: i'm not making a point either way. i'm strictly pointing out that you guys are complaining about the current state, whereas i'm arguing that there are a series of very reasonable decisions that get you to this state
[02:00] <broder> i'm also suggesting that you need to understand (even if you disagree with) those decisions in order to have a chance at coming up with a satisfactory alternative
[02:03] <bdrung> broder: i understand that you imported the package like dpkg-source gives them you.
[02:03] <bdrung> broder: you do use dpkg-source, aren't you?
[02:04] <broder> presumably
[02:05] <bdrung> you can give dpkg-source an parameter to not apply the patches and add 'unapply-patches' to debian/source/local-options
[02:05] <broder> sure
[02:05] <bdrung> then the patches are not applied in the branch and they will be applied when you build the source
[02:06] <bdrung> bzr bd builds the package outside the branch. therefore 'unapply-patches' in debian/source/local-options isn't required
[02:06] <broder> like i said, i don't actually feel like arguing about this right now, and haven't formed a well-thought out opinion on what the bzr importer in particular should do anyway
[02:07] <broder> i didn't actually mean to hit-and-run comment, so sorry
[02:08] <bdrung> broder: the question is where we should discuss this topic. in a bug report or on ubuntu-devel ML?
[02:08]  * psusi things u-d
[02:08] <psusi> thinks even
[02:08] <broder> u-d will get more eyes
[02:09] <bdrung> psusi: do you volunteer to write the initial mail? my bed needs me...
[02:10] <psusi> bdrung, if someone else doesn't, I'm sure I will eventually, but I actually can't post to the list without moderation yet, so ;)
[02:10]  * psusi really needs to get that motu application in
[02:10] <bdrung> psusi: just subscribe to it and then you can post without moderation
[02:11] <psusi> bdrung, I've been subscribed since like 2005.. a few years ago it went moderator and developer only and -discuss was created to be public
[02:11] <bdrung> wow, really?
[02:12] <psusi> lol... you didn't notice the reduction of noise? ;)
[02:12] <psusi> I'm subscribed to both and post to both, but my posts to devel sometimes don't make it at all, and if they do, take days for moderation
[02:13] <psusi> usually end up having a full conversation via the private Cc:s off list then a few days later, my replies finally appear on list
[02:13] <bdrung> psusi: my first mail to ubuntu-devel was on 2009-10-19 according to my email archive.
[02:13] <ScottK> bdrung: There's a UDD mail list that would be the best place to send it.
[02:13] <psusi> ohh, heh
[02:14] <psusi> there is?  hrm... I should get on that
[02:14] <ScottK> The issue has been discussed before.
[02:14] <ScottK> Yep.
[02:16] <bdrung> ScottK: my suggestion: use dpkg-source with '--no-preparation' - that's what sponsor-patch does
[02:16] <psusi> hrm... all of my mailing list folders won't fit on the screen anymore if I sign up for 2-3 more ;)
[02:16] <ScottK> bdrung: Thanks.  I'll have to try that.
[02:17] <psusi> at least I stopped drinking from the lkml fire hose
[02:33] <psusi> ok... complicated situation here and trying to sort out what I should do with the control fields... bug fix involves changes to 3 packages: upower, g-p-m, and indicator-session.  indicator-session and g-p-m already depend on upower
[02:33] <psusi> I'm thinking I should update those two depends to require the new version or greater, and add a Breaks: to upower for older versions of both upower and indicator-session, is that right?
[02:38] <andersk> Why did ghc6 6.12.3-1ubuntu6 change the ABI hash of unix from 49642 to e3bae?  In any event, that means that all the rdeps of libghc6-unix-dev-2.4.0.2-49642 need to be rebuilt.
[02:39] <Ampelbein> psusi: what does that bugfix do? does it change all 3 packages?
[02:40] <Ampelbein> psusi: and why 'Breaks:'? Does installing upower prevent older indicator-session versions from running?
[02:43] <psusi> yes, I have changed all 3 packages... I modified the dbus api between upower and g-p-m so that g-p-m will once again, properly lock the screen on suspend/hibernate.   I also removed the code that was added to indicator-session to lock the screen before asking upower to hibernate that was added I think as a workaround for the fact that g-p-m was broken and not doing it
[02:43] <psusi> so basically you need to upgrade all 3 packages in lock step
[02:48] <Ampelbein> psusi: ok, sounds like your plan is right.
[08:34] <bwright> Is usb-creator-gtk part of the Ubuntu project or is it an additional third party app?
[10:46] <cjwatson> ScottK: kdm> great, thank you
[11:06] <cjwatson> pitti: how is it possible to recover from http://launchpadlibrarian.net/66694492/buildlog_ubuntu-natty-powerpc.atk1.0_1.33.6-0ubuntu3_FAILEDTOBUILD.txt.gz ?
[11:07] <cjwatson> pitti: since atk1.0 is out of sync, libatk1.0-0 is uninstallable on powerpc
[11:07] <cjwatson> pitti: cdbs Depends: python-scour Depends: python-rsvg Depends: librsvg2-common Depends: libgtk2.0-0 Depends: libatk1.0-0
[11:08] <cjwatson> pitti: (this is bad for bootstrapping new architectures, too)
[11:24] <slangasek> cjwatson: bug #734471; I think the quickest way to recover is to upload cdbs w/o the python-scour dep
[11:25] <slangasek> (and then readd it after, I guess, until a better solution is found)
[11:29] <cjwatson> well, the bootstrapping problem will still be there
[11:30] <cjwatson> I'll note that in the bug
[11:56] <sabdfl> hello folks
[11:57] <sladen> hello Makr
[12:22] <Kre10s> I have a question about packaging. If a hardware manufacturer provides an open source driver... who is responsible for packaging it?
[12:22] <Kre10s> Am I allowed to package it?
[12:23] <Ampelbein> Kre10s: if the license allows redistribution, yes.
[12:24] <Kre10s> should I just read the license or send the manufacturer an email?
[12:24] <sladen> Kre10s: yes, of course.  Try packaging it and getting into a PPA ... check with #ubuntu-motu (Masters of the Universe) if you need help checking the licence to see if you're allowed to
[12:24] <sladen> Kre10s: have you got a URL to the licence?
[12:24] <Kre10s> hmm. i'll go get one.
[12:26] <Kre10s> heres the product http://www.peak-system.com/fileadmin/media/linux/index.htm and it says "The complete package is distributed under the GPL." GPL being a link to http://www.gnu.org/licenses/gpl.txt
[12:28] <Kre10s> so that means i can try packaging it!?!
[12:29] <Kre10s> I want to package it because I'm using it allot, and its bothersome to constantly install from source.
[12:29] <Ampelbein> Kre10s: yes, you are allowed to package and redistribute.
[12:29] <Kre10s> apt-getting it would be sweetness
[12:29] <cjwatson> while it's possible to package it independently, you should really ask them to get it integrated into the upstream kernel
[12:29] <cjwatson> out-of-tree kernel drivers tend to be sadness, ultimately
[12:30] <Kre10s> ah. because you have to compile it for all the different kernel versions.
[12:37] <cjwatson> Kre10s: or, nowadays, use dkms
[12:37] <cjwatson> but it's still better to have it integrated upstream
[12:37] <Kre10s> agreed.
[13:01] <bdrung> hi, does anyone else have bash completion problems in natty? Try "ls /de" and then press tab
[13:02] <bdrung> you will get "ls /dev " instead of "ls /dev/"
[13:04] <ankreloaded> bdrung: no mine is just fine
[13:07] <Ampelbein> bdrung: works for me on natty/amd64
[13:07] <bdrung> hm, maybe a configuration problem.
[13:07] <bdrung> do you know how to restore the configuration files of a package?
[13:09] <Ampelbein> bdrung: hmm, 'aptitude reinstall'?
[13:10] <ion> bdrung: Try resetting your .bashrc.
[13:28] <bdrung> Ampelbein: that doesn't bring the config files back
[13:29] <Ampelbein> bdrung: 'aptitude purge && aptitude reinstall' should do.
[13:30] <bdrung> Ampelbein: yes, that works (but not for every kind of package - non-leaf packages)
[13:32] <bdrung> thanks for all your comments. purging and reinstalling bash-completion fixes my issue
[13:38] <chrisccoulson> bdrung, have acroread installed by any chance?
[13:38] <bdrung> chrisccoulson: yes
[13:38] <chrisccoulson> bdrung, bug 716008
[13:38] <bdrung> (due to a bug in evince)
[13:38] <chrisccoulson> i guess i should reassign that
[13:38] <chrisccoulson> the acroread bash completion file is screwed
[13:39] <bdrung> good to know
[15:57] <ScottK> slangasek: What's the issue with python-scour on powerpc?  It broke my kdebase-workspace (for the kdm upstart fixes) upload?
[16:54] <psusi> cjwatson, ping, it's been 11 days since I made those minor cleanups you asked for in lp:~psusi/ubuntu/natty/parted/fix-dmraid and lp:~psusi/ubuntu/natty/dmraid/fixes
[17:11] <Ampelbein> hmm, can you access staging.lp.net via the python api? I get an "unauthorized token" error when trying 'lp-shell staging'
[17:22] <ScottK> Ampelbein: --> #launchpad, but I think staging was being retired.
[17:23] <Ampelbein> ScottK: oh, it is? thought only edge was put down. well then, testing scripts on live system ftw ;-)
[17:23] <Ampelbein> ScottK: thanks.
[17:23] <ScottK> Ampelbein: Maybe.  Dunno.
[17:23] <ScottK> In any case, ask #launchpad.
[17:30] <cjwatson> psusi: thanks, I'll look at them on Monday
[17:30] <cjwatson> ScottK,Ampelbein: staging isn't being retired as far as I know
[17:30] <ScottK> cjwatson: Yes, I was confusing it with edge.
[17:30] <cjwatson> Ampelbein: does https://lists.launchpad.net/launchpad-users/msg06239.html help?
[17:33] <Ampelbein> cjwatson: I did that conversion already, it is working on production. just not on staging. I just wanted to know if anyone else has the same problem. 'lp-shell' works, 'lp-shell staging' doesn't. (lp-shell is in ubuntu-dev-tools)
[18:44] <slangasek> ScottK: circular build dependency between cdbs and the GNOME library stack due to the added feature of cleaning up SVGs at build time (bug #734471); I'd been waiting for guidance from pitti here, but we seem to be blocking/breaking enough now that I'll upload cdbs to drop this dep today and unblock us
[18:44] <ScottK> slangasek: Thanks.
[18:45] <slangasek> (and then as long as I have a window where that circular dep is out of the way, I can upload fontconfig for multiarch :)
[18:46] <ScottK> Since I ping'ed you it also broke kdeedu.
[18:47]  * slangasek nods
[18:48] <ScottK> slangasek: Speaking of kdeedu, it looks like there's more GL in there than we thought (see 707794)
[18:48] <slangasek> yep, saw your mail
[18:48] <ScottK> OK.
[18:54] <cjwatson> slangasek: (I noticed the atk1.0 side of that breakage because it broke plymouth and gdm builds, BTW)
[19:07] <slangasek> cjwatson: right, I'll have a go at http://people.canonical.com/~ubuntu-archive/testing-ports/natty_outdate.html once cdbs is in
[20:09] <Laney> oh, cdbs is broken?
[20:15] <slangasek> Laney: on powerpc only; just fixed
[20:15] <slangasek> publishing this hour
[20:16] <Laney> yeah
[20:16] <Laney> will look out for it to mash retry
[20:21] <Laney> slangasek: or will you arrange a mass give-back?
[20:21] <slangasek> Laney: if you're around and at liberty to poke at it, I'd be grateful for the help
[20:21] <slangasek> I still have openjdk to try to tackle today
[20:25] <Laney> sure, i'll just hit it in a little while
[21:26] <ScottK> slangasek: Still seems brokenish.  I just retried kdebase-workspace on powerpc and got  cdbs : Depends: python-scour but it is not going to be installed
[21:26] <ScottK> (that one would have failed anyway due to pkg-kde-tools, but that's a separate issue)
[21:29] <slangasek> ScottK: I'm a muppet; I removed the build-dependency but not the dependency
[21:29] <slangasek> so that's another hour wasted
[21:30] <slangasek> fixing now
[21:30] <ScottK> Thanks to that I discovered pkg-kde-tools needs fixing, so it's not a complete waste.