[00:09] <keescook> oh whoa.  I didn't realize you could actully debdiff .deb files.  :P
[00:09] <elmo> haha
[00:09] <elmo> and changes files
[00:10] <keescook> yeah... just reading the manpage now.  :P  I've used it on .dsc for so long I didn't even think it could be used for other things. heh
[01:09] <Pelo> evening guys,  can I ask a silly question ?
[01:09] <Fujitsu> Pelo: Perhaps, if it is related to Ubuntu development.
[01:09] <Pelo> why doesn't the live cd default to vesa when detecting a nvidia or ati video card ?
[01:10] <Pelo> does that count ?
[01:13] <Fujitsu> That looks like an appropriate question, but I can't answer it.
[01:15] <Pelo> I've been giving out ubuntu cds and dvd telling ppl they could try it without installing but this particluar issue is becomming a problem, I get why it doesnt have ati or nvidia driver , the non FOSS thing, but I started to wonder why not just vesa in those case, that is what get's instaled anyway
[01:16] <LaserJock> Pelo: what does it do currently?
[01:17] <Pelo> LaserJock,  is just fails
[01:17] <LaserJock> hmm, I think it's supposed to fall back to vesa
[01:17] <Pelo> ifyou try the live cd or live dvd on a comp with either an nvidia or an ati videocard it just doesn,t recognise it
[01:18] <Pelo> LaserJock,  during the install yes,
[01:18] <Pelo> well in text mode instal anyway it will instal the vesa driver
[01:18] <Pelo> mind you,  I'M starting to wonder if it is not supposed to be fixed in gutsy
[01:19] <Pelo> I dont, hae a nvidia card myself so I don'T have this particualr problem but friends have , and there are a lot of ppl comming into the support channel with this issue as well
[01:20] <LaserJock> Pelo: I wonder if it's just certain cards or something
[01:21] <Pelo> LaserJock,  I think some older cards might work but they seem to be the exception
[01:21] <Pelo> any way I have to go,  consider it a suggestion for the hardy live cd if nothing else
[01:22] <Pelo> thanks for your time
[01:22] <LaserJock> thanks for stopping by
[03:20] <cellofellow> hello
[03:22] <cellofellow> Why did my spec, https://blueprints.launchpad.net/ubuntu/+spec/dapper-to-hardy, not get excepted and this one, https://blueprints.launchpad.net/ubuntu/+spec/lts-upgrades, did? They accomplish the same thing.
[03:23] <cellofellow> I think it has something to do with how I worded it, but not sure. I never submitted a spec before.
[03:23] <cellofellow> Why did my spec, https://blueprints.launchpad.net/ubuntu/+spec/dapper-to-hardy, not get excepted and this one, https://blueprints.launchpad.net/ubuntu/+spec/lts-upgrades, did? They accomplish the same thing.
[03:23] <cellofellow> I think it has something to do with how I worded it, but not sure. I never submitted a spec before.
[03:27] <slangasek> cellofellow: repeating yourself is not necessary...
[03:28] <slangasek> cellofellow: the reason lts-upgrades was accepted is that it's the one that includes the link to the full specification with design information, https://wiki.ubuntu.com/LTSUpgrades
[03:28] <slangasek> it appears that the lts-upgrades blueprint was also created 5 months earlier...
[03:31] <cellofellow> slangasek: sorry about the repetition, I just saw knew people in the channel and wanted them to hear too.
[03:31] <cellofellow> slangasek: I couldn't find dates in the Blueprints stuff.
[03:32] <slangasek> cellofellow: the dates are shown under "lifecycle" on the left
[03:33] <cellofellow> so, what's some advice for spelling out specs in the future
[03:33] <cellofellow> (I did try to find one that was like this before submitting. I guess I just didn't search the right terms.)
[03:35] <slangasek> cellofellow: well, in general terms, communicating with the developers who are going to have to do the work to make it happen is an important first step. :) For many specs, this happens at UDS where the developers are face-to-face
[05:22]  * lamont looks around for a package that delivers both python2.4 and 2.5 .py files
[05:22] <lamont> site-packages type, eh?
[05:22] <RAOF> lamont: python-pyinotify?
[05:22] <lamont> kewl
[05:22] <LaserJock> hmm, in general packages aren't supposed to do that are they?
[05:23] <lamont> IRC works even better than google for somethings...
[05:23] <RAOF> No, in general packages are supposed to ship .py for as many python versions as possible?
[05:23] <LaserJock> IRCpedia
[05:24] <RAOF> Oh.  Except they won't actually be shipping different .py files in the deb, the postinst script will be doing byte-compiling for all the installed python versions.
[05:24] <LaserJock> well, they should ship .py and let python-central/python-support handle versions
[05:24] <RAOF> Heh.  We converge on the answer from different directions :)
[05:29] <lamont> LaserJock: except that if you want pycentral to handle versions for you, you still have to build 2.4 and 2.5
[05:29] <lamont> as I've been learning.
[05:29] <LaserJock> why?
[05:30] <lamont> doko told me that if I want 2.5 versions, then I need to build them.. is that not the case>
[05:30] <lamont> package currently delivers python2.4/site-packages/$mumble...
[05:30] <LaserJock> hmm, that's weird
[05:30] <lamont> are you telling me that 2.5 will magically appear?
[05:30] <LaserJock> I thought so
[05:30] <lifeless> es
[05:30] <lifeless> bleh
[05:30] <lifeless> you tell pycentral what versions you want
[05:30] <lifeless> it then in the postinst symlinks and byte compiles appropriately
[05:31] <lamont> lifeless: and deliver .py files where?
[05:31] <lifeless> if you ahve a C extension they get built for the python version specifically.
[05:31]  * lamont notes that pyinotify specifically builds both versions
[05:31] <LaserJock> that's weird
[05:32] <LaserJock> I don't know why it would do that
[05:32] <LaserJock> unless it's legacy
[05:32] <lifeless> lamont: dpkg -L python-gmenu
[05:32] <lamont> maybe it cloned from another package like I just did from it??
[05:32] <lamont> hrm... OK.
[05:32] <lifeless> lamont: pyinotify probably has a C extension in it
[05:32]  * lamont tweaks his source again
[05:33] <lamont> hrm...  can I put wild cards in ${package}.files, I wonder....
[05:33] <RAOF> LaserJock: Yeah.  It's the C extension.  It has to be built against each python version.
[05:34] <RAOF> LaserJock: Or you get the pyinotify bug I fixed, where you could use it in 2.5 but not in 2.4 :)
[05:36]  * lamont can hardly wait to see if there are any .so files in the build
[05:37]  * RAOF thought ${package}.files was generally generated during package build?
[05:37] <lamont> RAOF: in my experience, I've generated it myself
[05:38] <lamont> as in it's checked into source control
[05:38] <RAOF> Maybe I was thinking of something else.
[05:42] <persia> lamont: Some of the automated package checkers say it's deprecated (although it may still be required for your packages)
[05:45] <lamont> given that dh_movefiles uses it, and I use dh_movefiles...... :-)
[05:47] <RAOF> Oldschool
[05:48] <LaserJock> lamont is deprecated ;-)
[05:50] <lamont> feh
[05:50] <lamont> you kids always creating new crackful ways of doing things...
[05:50] <lamont> why when I was a kid..... :-)
[05:50] <LaserJock> did you use CDBS?
[05:52]  * persia notes that dh_movefiles is more new-fangled than just calling install lots of times.
[05:53] <lamont> LaserJock: hell no.
[05:53] <lamont> CDBS is a maze of twisty mess
[05:54] <lamont> the only good thing about it is that it's miles less crackful than DBS
[05:54] <lamont> then again, when I look at a makefile, I want to look at a makefile
[05:54] <persia> I also like it because it tends to reduce the use of debian/rules as a "bash script"
[05:54] <lamont> not an include of something that takes side-effects from  a number of strange variables in the top level makefile
[05:56] <lamont> LaserJock: I expect that if I adopted a package using CDBS, it'd not be using CDBS sometime shortly thereafter.  (for DBS, make that certainly wouldn't be :)
[05:56] <lamont> and these days, ditto for dpatch/quilt/etc.
[05:56] <LaserJock> if it's a really easy package where you can do a 2-line debian/rules it's not bad
[05:57] <LaserJock> but I tend to stay away from it
[05:57] <lamont> first I'd have to learn CDBS.  and that would tend to make me drop in a trivial example debhelper makefile and be done.
[05:57] <LaserJock> seems like if I run into some problem it's always "solved" by some totally cryptic rule
[05:57] <lamont> my usual approach to fixing FTBFS packages with CDBS is to pester people who understand CDBS.
[05:58] <lamont> (since it's someone elses package, and ripping CDBS out to fix an ftbfs is kinda, um, rude. :)
[05:58] <LaserJock> heh, how about adding CDBS to fix a ftbfs? :-)
[05:59] <LaserJock> lamont: not a fan of dpatch?
[05:59] <lamont> I'd rather see my code as it will build.  dpatch isn't so bad, other than the pain of not seeing exploded/patched code while you're working on it.
[06:00] <lamont> SCM belongs in SCM.  implementing SCM in dpkg is kinda silly
[06:00] <LaserJock> so what do you do?
[06:01] <LaserJock> make upstream fix everything so you don't need patches? :-)
[06:01]  * lamont has the, uh, privilege of working on the debian-packaged kernel for his day job.  That package boasts the ability to produce any earlier version of the package from the source package.
[06:01] <lamont> LaserJock: git clone git://git.debian.org/~lamont/bind9.git
[06:01] <lamont> that'd be one of my packages
[06:02] <lamont> if you want to see the patches, go to the SCM.  if you want to build the source, there's this nice monolithic patch in diff.gz. :-)
[06:03] <LaserJock> right
[06:03] <lamont> I was using dpatch before (when my packages were all in cvs and arch and old bzr).  When I switched everything to git, I retired my dpatch usage.
[06:04] <LaserJock> not to bzr?
[06:04] <lamont> and adding cdbs to fix an ftbfs would be equally rude.... and very unlikely to be adopted by the debian maintainer (unless he told you to do it...), so your patch becomes unwieldy
[06:04] <lamont> I deal with git all day.
[06:04] <lamont> and bzr infrequently.
[06:05] <LaserJock> makes sense
[06:05] <lamont> and bzr and I didn't understand each other wrt repositories at the time.  so git won.
[06:05] <lamont> I expect that bzr has everything I care about now, so it's just a question of familiarity
[06:06] <lamont> and bzr checkouts have historically caused me pain in my bandwidth meter.  I expect that's improved now, too.  right lifeless?
[06:06]  * lamont has no real recent bzr history
[06:07] <LaserJock> lamont: how do you handle a new upstream release when the whole source is in git?
[06:07] <lamont> LaserJock: in the ideal case, I say 'git fetch origin' (see util-linux)
[06:07] <lamont> :)
[06:07] <LaserJock> well, yeah
[06:07] <ion_> I switched from bzr to git a while ago. Subjectively git seems faster (i haven’t done actual benchmarking, though) and i just love how it handles branches as opposed to bzr.
[06:08] <LaserJock> but that's more of a corner case at this point
[06:08] <lamont> in the less ideal case, I smash the new upstream in as one (or maybe more if I'm in a good mood) commits into either the upstream branch, or upstream git repo
[06:08] <LaserJock> do you keep debian/ in a separate branch?
[06:09] <persia> lamont: Do you use pristine-tar, or just pull the upstream externally?
[06:09] <ion_> I learned about ‘bzr switch’ after the fact, but it only comes a few steps closer to how nicely git handles them IMHO.
[06:09] <lamont> hrm.. of 9 packages: 1 in git upstream, 1 where I _am_ upstream (git), and 1 with published upstream cvs, 1 with unpublished upstream cvs, and the rest are tarball only uploads
[06:10] <lamont> LaserJock: debian exists only in the debian branch, which is derived from upstream.
[06:10] <LaserJock> ok
[06:10] <lamont> git branches are decended from things, not separate source trees.
[06:10] <lamont> so it makes sense (in some way) to have two repos for upstream and debian, or one repo for the combination.
[06:10] <lamont> different source on different branches is contrary to the design.
[06:10] <lamont> at least as far as I understand it
[06:11] <lamont> persia: pristine-tar?
[06:11]  * persia goes to find a pointer to docs
[06:11] <lamont> if there's an upstream SCM, I pull from it for my tree.  Where there's not an upstream SCM, then the upstream tarball gets to get unpacked and committed.
[06:11] <slangasek> pristine-tar is joeyh's "recreate tarballs from repos" trick
[06:11] <lamont> ah
[06:12] <lamont> given that gzip tends to give a different hash everytime I create a tarball, I just use the upstream tarball.
[06:12] <slangasek> which I'm still waiting to hear of a naming convention for, that's recommended for use with things like svn-buildpackage
[06:12] <persia> known to work with git, but I didn't know if anyone other than joeyh actually used it.
[06:13] <slangasek> lamont: it has an extension that's supposed to be usable for recreating tgz as well
[06:13] <persia> lamont: git://git.kitenet.net/pristine-tar/
[06:13] <lamont> I may have to look at that.
[06:15] <LaserJock> so the problem is that often the tarball downloaded from upstream has a different md5sum than a tarball created from the identical files in a SCM?
[06:16] <persia> LaserJock: Yes, and moreso that the gz of the tarball has a different checksum as well.
[06:16] <lamont> OTOH, I had a nice chat today with a coworker about how to have an upstream branch, from which was derived a debian branch, and package a .orig.tar.gz and a diff.gz that delivered a debian/patches/foo and friends, so that the build process could untar upstream/tarballs/*.gz and patch them, and such
[06:17]  * lamont throws nmap at the grinder again, just for good measure. I might actually manage an experimental upload tonight
[06:18] <lamont> ScottK: pinentry is your merge - I just did a trigger rebuild...
[06:18] <lamont> OTOH, no reason I can't do it
[06:19] <persia> lamont: It's late there: you may be waiting ~6-8 hours for a response
[06:19] <LaserJock> hmm, jbailey seems to be sending me lots of pharmaceutical offers ;-)
[06:22] <lamont> feh.  he can't stay up until 1:30 AM just to talk to me?
[06:22] <lamont> OTOH, bed time for me too... alarm clock in 5.5 hours.
[06:22] <ion_> Has anyone noticed compiz hanging, like, all the time, after an update a couple of days ago?
[06:22] <lamont> ion_: I thought that was it's purpose. :-)
[06:22] <ion_> I’ll take a look at LP bug reports.
[06:23] <lamont> (was that my out-loud voice?)
[06:23] <ion_> :-)
[06:25] <lamont>         dh_installman -pzenmap docs/zenmap.1
[06:25] <lamont> so why does zenmap.1 wind up in the nmap package instead, I wonder.
[06:26] <LaserJock> maybe CDBS hear your comments earlier and switched out dh_installman with it's own, more nefarious, version
[06:27] <lamont> heh
[06:28] <choudesh> where are the nightly build ISOs at for Hardy?
[06:28] <lamont> cdimage.ubuntu.com/daily or so
[06:28]  * lamont workraves while the build runs
[06:29] <choudesh> lamont: is the script available that starts this nightly ISO build?
[06:29] <lamont> ??
[06:30] <choudesh> what software do they use to create the nightly builds or do they just have scripts as cron jobs?
[06:30] <lamont> the script that starts the build is run either from cron, or manually, on some machine in the data center.
[06:31] <lamont> and, iirc, that stuff is checked into bzr somewhere.
[06:31] <lamont> the livefs is built by the package livecd-rootfs, iirc
[06:31] <lamont> and that's in the archive
[06:31] <LaserJock> choudesh: what are you wanting to do?
[06:32] <lamont> LaserJock: oh sure, remove the mystery...
[06:32] <choudesh> LaserJock: setup a nightly build iso repo for a ubuntu derivative
[06:32]  * lamont is trying to figure out if he wants someone to kick a daily build, or if he wants to build a custom CD
[06:32] <LaserJock> lamont: I was figuring the later
[06:33] <LaserJock> choudesh: you might want to check out https://code.launchpad.net/~kamion/ubuntu-cdimage/mainline
[06:33] <lamont> yeah... so he wants the script that builds the ISO, not the script that starts it... :)
[06:33] <choudesh> ahh - that is where it is.
[06:33] <choudesh> thanks.
[06:33] <lamont> which is just me having challenges parsing english tonight
[06:33] <lamont> choudesh: and that looks to be the right repo
[06:34] <LaserJock> choudesh: make sure to look in config/devel , it has more code to look at
[06:34] <choudesh> ight
[06:34] <choudesh> thanks guys
[06:39] <lamont> LaserJock: I wasn't remembering where kamion kept it... thanks
[06:40] <LaserJock> np, I did some debian-cd/ubuntu-cdimage patching for Edubuntu and learned about that
[06:41]  * lamont needs to clean that code up for non-alternate ISOs for hppa/ia64
[06:41] <lamont> it currently has a "FIXME" for those...  and they're not likely to clear the cutline any release soon
[06:42] <lamont> unless I either do it myself, or find someone else to badger into it.
[06:55]  * lamont sleeps.
[07:23] <warp10> Hi all!
[07:24] <gQuig1> is this where I should post for guidance with getting a blueprint accepted?   (https://blueprints.launchpad.net/ubuntu/+spec/no-mono-by-default)  Need to know what to do next
[07:26] <LaserJock> gQuig1: generally you want to have some discussion around a spec
[07:26] <LaserJock> gQuig1: I suspect there will be lots of discussion around that subject
[07:26] <LaserJock> probably a good place to get feedback would be the ubuntu-devel-discuss mailing list
[07:27] <gQuig1> LaserJock: has been on forum, ok.. I'll post to the mailing list
[07:27] <gQuig1> http://ubuntuforums.org/showthread.php?t=634805
[07:28] <LaserJock> I'm aware of the thread :-)
[07:29] <LaserJock> gQuig1: you might want to try to come up with some more info for implementation, like what you're going to propose to replace the current mono apps
[07:32] <gQuig1> That's really only F-Spot..
[07:32] <gQuig1> and gThumb does something very similar to F-Spot
[07:34] <gQuig1> (https://blueprints.launchpad.net/ubuntu/+spec/hardy-reducing-duplication for more info)
[07:34] <gQuig1> but you are right, I need to make my blueprint clearer in that regard
[07:36] <LaserJock> gQuig1: right, but if you're proposing to remove software you need to have good replacements so that's gonna be key to your argument
[07:37] <gQuig1> LaserJock: if the apps in question already have their primary functionality covered in other default applications?
[07:37] <LaserJock> well, the argument will be that they aren't covered
[07:38] <LaserJock> Tomboy != StickyNotes, Gthumb != Fstpot for instance
[07:38] <LaserJock> FSpot
[07:40] <gQuig1> what critical functionality is not in StickyNotes and is in Tomboy?
[07:41] <LaserJock> gQuig1: quite a bit actually
[07:42] <LaserJock> I can see F-Spot and Gthumb being more similar than Tomboy and StickyNotes
[07:42] <gQuig1> the only thing I know of is WikiLinking
[07:42] <LaserJock> Tomboy is killer
[07:42] <gQuig1> really?  I had thought the opposite
[07:42] <LaserJock> syncing, exporting to HTML, and linking is good
[07:43] <gQuig1> to properly do this, I am going to have to do in-depth reviews of all the apps in question
[07:43] <LaserJock> that would be a good idea
[07:43] <LaserJock> a feature comparison would be good
[07:44] <LaserJock> I think arguments of "we can get the same functionality without the overhead" will go much further than "Mono is evil"
[07:44] <gQuig1> definitely
[07:47] <pitti> Good morning
[07:47] <LaserJock> ah pitti
[07:47] <LaserJock> morning
[07:47] <ion_> Hi
[07:47] <LaserJock> pitti: I have a question/request for you
[07:47] <ion_> Now my ISP offers native IPv6 connectivity for free, yay!
[07:48] <LaserJock> pitti: I need goffice0.4 un-blacklisted
[07:48] <gQuig1> good night all.  thanks LaserJock
[07:48] <warp10> Morning pitti! :)
[07:48] <LaserJock> gQuig1: night
[07:48] <pitti> LaserJock: ah, can we sync from Debian now?
[07:48] <pitti> hey warp10! back again? how was the moving?
[07:48] <LaserJock> pitti: for some reason Debian put it into oldlibs, the package is only 1 month old
[07:49] <LaserJock> pitti: goffice0.4 was created to provide a lib for packages that use the stable version
[07:49] <LaserJock> gnumeric uses the unstable version 0.5 so that's what goffice is at
[07:49] <warp10> pitti: yep, I am back! Unfortunately I lost the fight against that hated usb modem :-S
[07:50] <LaserJock> pitti: does that make sense?
[07:51] <pitti> LaserJock: and you need 0.4 for something?
[07:51] <LaserJock> yep
[07:51] <LaserJock> gchemutils/gchempaint use it
[07:51] <LaserJock> I'm waiting on goffice0.4 to merge them
[07:57] <pitti> alright, I'll sync it then
[07:57] <LaserJock> ok, thank you very much
[07:57] <LaserJock> chemists around the world will thank you :-)
[08:07] <dholbach> good morning
[08:08] <ion_> Good whatever.
[08:15] <MacSlow> Greetings everybody!
[08:18] <stgraber> moin
[08:20] <mdke> heya dholbach
[08:21] <dholbach> hey mdke
[08:21] <mdke> dholbach: colin asked me yesterday to have a look at updating gnome-user-docs; I've created an ubuntu-hardy branch in Launchpad, which is the ubuntu-gutsy branch, merged with Gnome svn. I don't know whether there is anything we should merge from Debian
[08:23] <dholbach> mdke: slomo did the update in debian - you could either check out what was changed in debian or ask him if it's worth
[08:23] <mdke> dholbach: ok, I'll try and do that
[08:24] <dholbach> mdke: great
[08:25] <dholbach> mdke: just file a upload request bug and subscribe ubuntu-main-sponsors once you're done
[08:25] <mdke> dholbach: thanks, I will.
[08:25] <dholbach> rock on
[08:26] <TheMuso> Would a core dev be so kind as to sponsor bug 172310 please? Gnome-orca needs it to function. Thanks in advance.
[08:26] <ubotu> Launchpad bug 172310 in brltty "Please upload merged brltty 3.9-4ubuntu1" [Undecided,New] https://launchpad.net/bugs/172310
[08:38] <slomo> dholbach, mdke: i only updated it to the newer upstream version which had many updates from the ubuntu package it seems...
[08:40] <mdke> slomo: the upstream version only has added translations. There are a few places where the English text differs in Ubuntu from upstream, but that's because Ubuntu's desktop is a little different to regular Gnome
[08:42] <mdke> slomo: so no changes to the packaging I need to worry about?
[08:43] <slomo> mdke: nope
[08:45] <mdke> slomo: thanks, that's very helpful :)
[09:10] <geser> morning
[09:10] <geser> pitti: please give-back: centerim. Thanks
[09:10] <pitti> geser: good morning! done
[09:44] <tkamppeter> pitti, hi
[09:45] <Riddell> pitti: please give back kdepimlibs
[09:46]  * pitti just read 'kdepimplibs' and thought "WTH..."
[09:46] <pitti> hi tkamppeter
[09:46] <pitti> Riddell: done
[09:47] <tkamppeter> pitti, it is about bug 172264
[09:47] <ubotu> Launchpad bug 172264 in ghostscript "[Gutsy SRU Request] Ghostscript in Gutsy and Hardy is not able to print encrypted PDFs out of Adobe Reader 8.1.1" [High,Fix released] https://launchpad.net/bugs/172264
[09:47] <StevenK> pitti: kdepimplibs is for KDE 4 :-P
[09:47] <Riddell> thanks pitti
[09:47] <pitti> tkamppeter: the upstream bug didn't enlighten me sufficiently, so I'd like to ask you about some insights
[09:48] <tkamppeter> It is really strange that this problem gets fixed by simply changing the size of a buffer, for me a buffer size change should only influence performance.
[09:48] <pitti> tkamppeter: right, and that's what makes me nervous
[09:49] <pitti> as if it wouldn't work with the n+1st test case, and/or break PDFs which work fine ATM
[09:49] <tkamppeter> Yes it can easily happen that this fix only helps on some files
[09:50] <tkamppeter> pitti, perhaps you should ask on the gs-devel@ghostscript.com list or on the #ghostscript IRC channel.
[09:52] <pitti> tkamppeter: can you please ask on the upstream bug?
[09:53] <pitti> (sorry, swamped)
[10:05] <tkamppeter> pitti, I will talk with them on IRC.
[11:05] <Riddell> pitti: hal broke my compile http://paste.ubuntu-nl.org/47814/
[11:05] <Riddell> pitti: it that caused by your upload yesterday?
[11:06] <pitti> Riddell: compile?
[11:06] <pitti> Riddell: very well possible, sorry about that; where does that happen?
[11:07] <Riddell> pitti: it happened in my compile of kdepimlibs in the buildds, but presumably any fresh hal install will fail
[11:07] <Hobbsee> BenC: :(
[11:07] <pitti> Riddell: can you please file a bug about this and subscribe me? I'll track this down this afternoon
[11:14] <Riddell> pitti: bug 175525
[11:14] <ubotu> Launchpad bug 175525 in hal "hal fails to install" [Undecided,New] https://launchpad.net/bugs/175525
[11:14] <Fujitsu> .win 17
[11:14] <Fujitsu> Oops.
[11:15] <pitti> Riddell: thanks
[11:16] <pitti> Riddell: please just add the failed builds to that bug, I'll give them back once it's fixed
[11:17] <Hobbsee> ion_: which video card?
[11:19] <Hobbsee> ion_: and if you're only getting a crash every 10 or so minutes, you're lucky...
[11:19]  * Hobbsee wonders if hte old compiz versions still install, and crash less.
[11:19] <ion_> 01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4800 SE] (rev a1)
[11:19] <ion_> The proprietary :-( driver.
[11:20]  * Fujitsu managed to fully log in once out of a few times.
[11:21] <Hobbsee> urg
[11:22] <ion_> I had while read; do pkill -9 compiz; done running in the virtual console for a while, until i got fed up and switched to metacity. :-P
[11:23] <ion_> It didn’t help that X insists on immediately switching back when i hit ctrl-alt-F1.
[11:24] <Hobbsee> that's consolekit
[11:25] <stgraber> Hobbsee: talking about the : compiz eats 100% of my CPU and makes the whole session to freeze ? :)
[11:25] <Hobbsee> stgraber: yup
[11:26] <Hobbsee> i'ts really getting overrated.
[11:26] <stgraber> I had this one after the I updated to the new compiz on my laptop (Intel card)
[11:26] <stgraber> I'm currently running metacity because of it
[11:26] <Hobbsee> yup.
[11:26] <Hobbsee> same here
[11:26] <Hobbsee> it's just not worth crashes every few minutes
[11:26]  * Fujitsu too.
[11:26] <Fujitsu> Yay for running dev releases.
[11:27] <stgraber> we have to test and debug, no ? :) As soon as I don't have any libc/kernel/xorg issue I'm happy to run the dev release
[11:28] <stgraber> running metacity instead of compiz isn't really a problem, just a bit annoying :)
[12:38]  * lamont yawns, waves
[12:56] <pitti> hey lamont
[12:56] <pitti> hi Hobbsee
[12:59] <soren> hey lamont.
[13:00] <pitti> lamont: what's the plan with your 5 outstanding merges? will you do them or shall we spread them amongst the distro team?
[13:01] <pitti> lamont: db4.2 is a sync, doing now
[13:01] <ogra> pitti, before you nag me as well, ltspfs will see a new upstream before feature freeze and we package that independently from debian ...
[13:02] <pitti> ogra: I won't, but thanks :)
[13:02] <ogra> :)
[13:02] <soren> I'll file the sync request for e2fsprogs in a minute..
[13:03] <pitti> soren: ah, is it?
[13:03] <soren> That's my conclusion, yes.
[13:03] <pitti> soren: I looked at it a while ago, and Ian's patch wasn't directly applied
[13:03] <soren> No, it wasn't.
[13:03] <pitti> might be that it was solved in a more general fashion
[13:03] <soren> But Ted T'so implemented a different workaround that looks more correct.
[13:03] <pitti> ah, cool
[13:04] <soren> Ian's patch made e2fsck ignore mount times in the future. Ted's patch add a new configurable to e2fsck.conf that can be set to allow mount times (and inode times) to be up to 24 hours in the future to account for differences in timezone settings.
[13:05] <soren> ...and he even took care to enable it on Ubuntu and not in Debian.
[13:05]  * persia notes that there are actually 25 timezones
[13:06] <pitti> ScottK: would you mind merging pinentry? lamont only touched it for a rebuild, and you actually seem to care about that package
[13:06] <soren> lamont: Could you add lpia to the list of archs for which we build syslinux?
[13:07] <pitti> lamont: are things like http://merges.ubuntu.com/libt/libtool/libtool_1.5.24-1ubuntu1.patch still necessary? hppa should have caught up now with building?
[13:08] <lamont> pitti: I need to work with doko and get java bootstrapped... hence the stalling on libtool, gettext, and such
[13:08] <lamont> s/bootstrapped/bootstrapped on hppa/
[13:08] <pitti> lamont: ah, so the plan is to do that and then drop the delta
[13:08] <lamont> right
[13:08] <pitti> cool, thanks
[13:08] <soren> lamont: Or is there someone more appropriate I should be asking?
[13:09] <lamont> and yeah, pinentry would be cool if ScottK did it, otherwise I'll just take it cold if no one beats me to it.
[13:09] <lamont> soren: I'd be the right victim
[13:09] <soren> lamont: Cool.
[13:09] <lamont> or infinity or elmo
[13:09] <lamont> committed.
[13:10] <lamont> soren: fwiw, tradition is to send email to the 3 of us
[13:10] <soren> lamont: Oh, I see.
[13:10] <lamont> that way we can silently ignore stupid requests together. :-)
[13:10] <soren> Hah!
[13:10] <soren> Well, up until about a week ago I had no idea such a thing as PaS existed. :-/
[13:11] <lamont> "please make this change.  here's a copy of the irc log where the maintainer agreed with me. .... "<maintainer> I think it would be better to get the port done" ...'
[13:11] <lamont> yes, well.
[13:11] <ScottK> pitti: I can try and take a look at it today or tomorrow, but all I did was make sure it met your requirements (not build the GTK version) for Main.
[13:12] <pitti> ScottK: I see; well, please let us know if you don't care/don't have time
[13:13] <ScottK> pitti: I'll try to find time today,  If not I'll give you a ping.  I hadn't noticed it as I just search for my name on the merges list.
[13:13] <pitti> ScottK: thanks
[13:13] <soren> lamont: Do I need to reupload to have a build record created for lpia or will that magically happen somehow?
[13:14] <lamont> it should be automagic
[13:14] <soren> lamont: Cool.
[13:14] <soren> lamont: Thanks very much.
[13:14] <lamont> ISTR that LP autosyncs PaS every so often (15min??)
[13:14] <lamont> so if there's no build record in 90 min or so, then bitchslap #launchpad. :0)
[13:14] <lamont> well, gently... so they can tell you who to really pester.
[13:14] <lamont> in any case, uploads should not be required
[13:15] <pitti> soren: try #soyuz instead
[13:15] <soren> lamont: Ah, it's just a direct sync from Debian?
[13:16] <soren> lamont: Or what do you mean by "autosync"?
[13:16] <lamont> yep
[13:16] <lamont> we share the file
[13:16] <lamont> which has occasionally been interesting..
[13:17] <soren> lamont: How so?
[13:17] <soren> lamont: Well, adding lpia might have been a bit controversial, I guess?
[13:18] <lamont> my favorite ever was a powerpc kernel package that was ": powerpc i386"
[13:18] <lamont> with a comment of "# I feel dirty - lamont"
[13:25] <soren> lamont: Erm.. Ok. :)
[13:26] <lamont> it built an arch-all package...
[13:26] <ogra> hmm, the devscripts update in debian adds a libfile-desktopentry-perl build-dep ... its apparently used for creating .menu files from .desktop .... do we drop that build-dep or do we want that lib in main ?
[13:26] <soren> lamont: Oh, right.
[13:30] <doko_> lamont: getting java bootstrapped is easy; getting a working java bootstrapped is more difficult ;-p
[13:45] <lamont> doko_: I'm into option #2. :-)
[13:45] <lamont> OTOH, you get your unaligned loads/stores.
[13:47] <doko_> lamont: gcj-4.2 doesn't require java to build; that should be buildable on its own. then you face a problem building ecj and gjdoc. suggested workaround: don't build from source, but build-depend on the just built libecj-java, and build from bytecode. The same should be done by gjdoc after splitting out an libgjdoc-java
[13:49] <lamont> doko_: that almost made sense.
[13:50] <lamont> I understand the words, I'm just not sure how they translate into actions... it might help if I had any clue about java... :(
[13:51] <lamont> what I need is a series of steps to get me a set of debs that I can use to build gcj-4.2, ecj, and gjdoc from source, and then use those binaries to build all 3 all over again
[13:52] <doko> lamont: continuing on private channel ...
[13:52] <lamont> ok. thanks
[14:08] <soren> slangasek: Around yet?
[14:23] <warp10> Hi all!
[14:40] <warp10> pitti: May I request a sync for libpcap-ruby?
[14:40] <pitti> warp10: sure, if you checked it; please file a sync bug
[14:43] <warp10> pitti: done. Bug 175564
[14:43] <ubotu> Launchpad bug 175564 in libpcap-ruby "Please sync libpcap-ruby 0.6-7  (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/175564
[14:45] <pitti> warp10: ack'ed, thanks
[14:45] <warp10> pitti: :)
[15:13] <soren> What are you guys doing to the Vcs-* headers when merging?
[15:14] <soren> I've been renaming them to XSBC-Original-Vcs-blah..
[15:14] <seb128> I don't change those
[15:15] <soren> Oh, really?
[15:15] <soren> On purpose?
[15:15] <seb128> why should we change them?
[15:15] <soren> Because they're wrong?
[15:16] <seb128> well, that's where the package is maintained out of the Ubuntu changes
[15:16] <soren> They tell you where Debian maintains the packages, so not changing them is misleading.
[15:16] <seb128> right, I don't care enough to create extra delta ;-)
[15:17] <soren> I think it'd be quite nice if I could actually trust apt-get source's warnings about the package being in a VCS somewhere.
[15:17] <seb128> I guess that using XSBC-Original-Vcs would make sense
[15:18] <soren> Cool. Hoever, two days before import freeze is not a quite optimal time to agree on changing them. :)
[15:18] <persia> seb128: Can that be done magically by the sync scripts?  That's a painful delta to coordinate.
[15:19] <soren> persia: By sync scripts, you mean MoM?
[15:19] <seb128> persia: it could be handled the same way that the maintainer change, do you have code to do those?
[15:19] <persia> soren: I don't think so: I was thinking of the scripts the archive admins use to pull from Debian for autosync or a sync request (is that really MoM?)
[15:19] <soren> persia: No, that's not mom.
[15:20] <soren> persia: Well, in the case of a sync, the headers are acutally correct.
[15:20] <persia> seb128: Hmmm....  Maybe.  If we only do XubuntuY, I guess it does make sense (and would certainly make apt-get source less confusing)
[15:21] <soren> persia: Since the package as is is in fact maintained in the vcs specified.
[15:21] <seb128> persia: well, the change make sense only for ubuntu version
[15:21] <persia> soren: Right, although that wouldn't be the appropriate place to make a change in many cases.
[15:21] <soren> It would be nifty if MoM renamed them, though. Then it would be up to us to add any Ubuntu specific ones.
[15:21] <seb128> persia: packages synced on Debian use the vcs indicated there
[15:21] <ScottK> pitti: I'm looking at pinentry now.  Is fixing the encoding of a non-UTF8 debian/copyright file worth adding to the Ubuntu/Debian diff over?
[15:21] <seb128> ScottK: no
[15:22] <persia> seb128: Right, but if I want to patch a Debian package, I don't want to do it in Debian.  As a result, I just completely ignore VCS-*, which isn't necessarily ideal either.
[15:22] <ScottK> seb128: Thanks.
[15:22] <seb128> ScottK: is there other ubuntu changes?
[15:22] <ScottK> seb128: There are.
[15:22] <Keybuk> soren: if MoM is involved, it implies that the package has *already* been patched
[15:22] <seb128> k, so it's up to you, doesn't really hurt
[15:22] <ScottK> My question is should I add to the pile.
[15:22] <seb128> you should send that to debian though
[15:22] <Keybuk> which implies that the maintainer was previously negligent and forgot to update control frields
[15:23] <Keybuk> (and likely forgot to update the maintainer too)
[15:23] <Keybuk> I think we shouldn't encourage that
[15:23] <ScottK> seb128: OK.  I'll do that (send it to Debian, but not sweat it for the merge).
[15:23] <soren> Keybuk: Point.
[15:24] <persia> Keybuk: Are you saying that updating VCS-* should have been done as part of variation?
[15:26] <Keybuk> yes
[15:26] <Keybuk> likewise for updating maintainer field
[15:27] <persia> Right.  We've the spec on the maintainer field, but no spec on Vcs-*.  As a result, I think there are heaps of merges where the first was changed, but not the second (for which the script seb128 mentioned above could help).
[15:27] <persia> On top of that, for syncs, we likely want to patch in Ubuntu after DIF, and push to Debian, rather than expecting work in Debian directly, which is why I wonder if we can do a sourcepackagemange type thing (although that makes it all very painful)
[15:30] <ScottK> lamont: I've done the pinentry merge.  Care to sponsor it?
[15:33] <lamont> ScottK: email me details, and sign your changes file.  I'll verify sig, build, resign, and upload.
[15:33]  * lamont heads for a meeting, aware that the weather is gonna make him, uh, late.
[15:39]  * soren lets out a deep sigh and goes to work on the multipath-tools merge
[15:39] <soren> Keybuk: I assume you're doing devmapper and mdadm?
[15:41] <Keybuk> soren: I haven't looked at them
[15:41] <Keybuk> feel free to
[15:41] <soren> Keybuk: They've got your name written all over them.
[15:41] <Keybuk> be sure to keep all our changes, since we worked hard on them :-)
[15:41] <Keybuk> and in the mdadm case, that does involve dropping almost all of the Debian stuff <g>
[15:41] <Keybuk> yes...
[15:42] <Keybuk> that's because I happened to touch them last
[15:42] <Keybuk> I have zero time for merges sadly
[15:42] <soren> I think I'll have my hands full with multipath-tools for now.
[15:42] <soren> Keybuk: Ok... I'll see if I can fit them in.
[15:42] <ScottK> lamont: Mailed.
[15:45] <Keybuk> soren: devmapper is easy, I'll do that one right now :)
[15:45] <soren> Keybuk: Coolness.
[15:45] <sivang> Howdy all
[15:45] <sivang> hey Keybuk
[15:46] <sivang> has anyone had any experience booting ubuntu onto a DBAu1550 based AMD evaluation board or is ubuntu mobile only ready for i386 architectures for now?
[15:47] <Keybuk> was that a question for me?
[15:47] <seb128> keescook: bug #175573 in case you didn't read it
[15:47] <ubotu> Launchpad bug 175573 in libcairo "libcairo2_1.4.10-1ubuntu4.2 is still broken - some text is not rendered" [Undecided,New] https://launchpad.net/bugs/175573
[15:49] <soren> Keybuk: Erk... The madadm merge looks like no fun at all.
[15:51] <Keybuk> soren: indeed
[15:51] <Keybuk> is there any particular reason to merge it at all?
[15:51] <soren> I was just thinking the same thing.
[15:52] <soren> Well, we can sync up to the same upstream release, but trying to merge the Debian specific changes seems pointless.
[15:58] <sivang> hey soren
[16:00] <soren> Hi, sivang! Long time!
[16:02] <evand> can someone in core-dev sponsor http://people.ubuntu.com/~evand/upload/partman-crypto_24ubuntu1.dsc ?
[16:03] <sivang> soren: indeed, long long time
[16:04] <sivang> soren : but I'm coming back gradually
[16:04] <soren> \o/
[16:27] <pitti> evand: grabbing
[16:27] <evand> thanks pitti
[16:28] <pitti> evand: MoM introduced a lot of *.po noise, did you remove that from the delta?
[16:29] <pitti> evand: or, asked the other way round, can you please pastebin a debdiff between 22 and 22ubuntu1?
[16:29] <pitti> evand: oh, nevermind; we actually added templates
[16:30] <pitti> evand: uploaded, thanks
[16:30] <evand> thanks, much appreciated!
[16:35] <Keybuk> MoM always creates po noise
[16:40] <Keybuk> hmm, how long does debbugs normally take?
[16:40]  * Keybuk has quite honestly forgotten
[16:42] <pitti> Keybuk: last time someone told me it runs at :03 and every 15 minutes
[16:42] <pitti> but I think it's faster nowadays
[16:42] <pitti> or I was exceptionally lucky recently :)
[16:42] <Keybuk> hmm
[16:43] <Keybuk> I've been waiting over 30 minutes
[16:43] <pitti> it actually got delivered? you mentioned a problem with local MTA and relaying?
[16:45] <seb128> I sent a bug some minutes ago, took 3 minutes to get the ack mail for this one
[16:48] <Keybuk> I assume it got delivered
[16:48] <Keybuk> I got a Cc, certainly
[16:58] <Keybuk> clearly I am being stupid here
[16:59] <Keybuk> but why can I not get any debian.org host to accept these bugs?
[16:59] <Keybuk> Connecting to bugs.debian.org via SMTP...
[16:59] <Keybuk> Unable to send report to scott@ubuntu.com: 550 relay not permitted
[17:06] <Keybuk> also my user tags don't appear to work
[17:09] <pitti> Keybuk: ah, so the bug was created, but you didn't get the confirmation email?
[17:09] <Keybuk> I think I had everything all ways then :)
[17:09] <Keybuk> first time I only got the Cc, not the created bug
[17:09] <Keybuk> second time I got the bug created, but no Cc
[17:09] <Keybuk> third time I got both
[17:09] <Keybuk> still no user tags though
[17:10] <Keybuk> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455747
[17:10] <ubotu> Debian bug 455747 in devmapper "udev support" [Wishlist,Open]
[17:10] <Keybuk> ^ has them, but they're not shown in the web interface
[17:10] <pitti> ah, I just found that bug, too
[17:11] <Keybuk> so that merge took me two minutes to do
[17:12] <Keybuk> and over an hour to extract the patches and then fight with debbugs to submit them
[17:12] <pitti> Keybuk: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ubuntu-patch;users=ubuntu-devel@lists.ubuntu.com has your bug, so your usertags work
[17:12] <Keybuk> pitti: no it doesn't?
[17:13] <Keybuk> it has a different bug that I forcibly added the tags with bts ?
[17:13] <pitti> Keybuk: it does show 455745, isn't that the one you just submitted?
[17:13] <keescook> seb128: thx, noted.
[17:13] <Keybuk> one of them
[17:13] <Keybuk> I also submitted 455747
[17:13] <pitti> ah, I just found the other one
[17:14] <Keybuk> I never thought I would say this, but debbugs makes LP seem painless and pleasant to use
[17:15] <pitti> heh, I tend to agree; it evolved a lot
[17:15] <pitti> although, when you are used to it, submitting an existing patch to debian is a matter of 2 minutes
[17:20] <Keybuk> anyway, devmapper merge done :-)
[17:34] <soren> Keybuk: Are you familiar with submittodebian?
[17:35] <Keybuk> no
[17:38] <soren> It extracts the debdiff between the two topmost revisions in debian/changelog (assuming you have the corresponding .dsc's in the parent directory), extracts the topmost changelog entry and turns those two into a bug report to Debian by way of reportbug.
[17:38] <geser> has someone some time to sponsor bug #157668 and bug #174749?
[17:38] <ubotu> Launchpad bug 157668 in scons "[Merge] scons 0.97.0d20071203-1ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/157668
[17:38] <ubotu> Launchpad bug 174749 in graphviz "[hardy] Drop libttf-dev from Build-Depends" [Undecided,New] https://launchpad.net/bugs/174749
[17:38] <soren> Your case is clearly more advanced, but generally it makes the hassle of dealing with Debian's bts minimal.
[17:39]  * pitti finds reportbug more time consuming than just creating a mail with explanations and the patch attachment to submit@b.d.o
[17:40]  * soren agrees in the general case
[17:40] <pitti> soren: it's nifty if the debdiff is just one atomic change, though
[17:40] <soren> pitti: Precisely.
[17:41] <Keybuk> in this case, I had three patches to submit upstream, and some that were ubuntu specific
[17:42] <soren> Keybuk: Right. Clearly a case where you need to go manual, but in the case of single bug fixes or feature additions or whatever, it's quite nice.
[17:46] <geser> are patches for lpia Ubuntu-specific or should they get forwarded to Debian?
[17:47] <Keybuk> soren: does it need a local MTA?
[17:47] <soren> Keybuk: It uses whatever reportbug uses.
[17:47] <soren> Keybuk: ...so no.
[17:47] <Keybuk> reportbug does though?
[17:47] <soren> Keybuk: No?
[17:47] <Keybuk> see above
[17:47] <soren> Keybuk: reportbug by default uses fiordland, afair.
[17:47] <Keybuk> it utterly failed
[17:47] <soren> How far?
[17:48] <Keybuk> I got relay access denied by whatever it was trying to use
[17:48] <soren> Right, it's trying to use fiordland.
[17:48] <Keybuk> which doesn't work, so it does need a local MTA :)
[17:49] <soren> You can configure it to use your isp's mta if you want.
[17:49] <soren> I agree that reportbug's default settings are on crack.
[17:49] <Keybuk> no, I can't
[17:49] <soren> Keybuk: *I* can.
[17:49] <Keybuk> because it doesn't support specifying a client certificate for connecting to it
[17:50] <soren> Oh.
[17:50] <soren> Your ISP requires that?
[17:51] <Keybuk> my mail server does yeah
[17:51] <pitti> soren: what? why should fiordland relay mail to the debian BTS?
[17:51] <Keybuk> why can't reportbug just use bugs.debian.org by default?
[17:52] <Keybuk> if it can do SMTP, why does it need a relay?
[17:52] <soren> pitti: It shouldn't.
[17:52] <soren> pitti: Hence: The default settings are on crack.
[17:52] <pitti> ok :)
[17:53] <soren> Keybuk: No idea.
[17:53] <soren> Keybuk: Well, a lot of ISP's block port 25 outgoing.
[17:53] <soren> Yes, I know that blocks fiordland, too.
[17:53] <soren> I'm just saying.
[17:53] <soren> Did I mention I think the default settings are on crack? :)
[17:54] <soren> I don't have any (much) better suggestions, though.
[17:54] <evand> soren: Do you mind taking a quick look at this and sponsoring it if it's ok.  It's a very small delta against the syslinux package to get rid of a reference to "CD2": http://people.ubuntu.com/~evand/upload/syslinux_3.53-1ubuntu2.dsc
[17:54] <soren> A one-size-fits-all approach to sending an e-mail is hard to find these day.s
[17:54] <Keybuk> if only you could ask evo to send a mail via D-BUS :-)
[17:54] <pitti> DMTP?
[17:54] <soren> evand: I'd love to. I thought about doing it yesterday, too, but couldn't be bothered, so thanks!
[17:55] <evand> ah, thank you
[18:11] <soren> evand: Uploaded. Thanks!
[18:12] <evand> thank you
[18:42] <slangasek> soren: moo
[18:57] <alex-weej> amyone know where i can find debugging symbols for hardy?
[18:57] <alex-weej> *anyone
[18:58] <alex-weej> i added the ddebs.ubuntu.com repo but the debugging symbols are out of date even for hardy
[18:58] <alex-weej> in particular, i need symbols for libgnome-keyring0
[19:02] <geser> alex-weej: pitti should hopefully know it
[19:02] <alex-weej> i am building the package myself for now but i'd really like to know
[19:03] <alex-weej> hum, that didn't work
[19:03] <alex-weej> i just built it myself, how do i get the debugging symbol packages? :E
[19:04] <geser> alex-weej: have your pkg-create-dbgsym installed?
[19:04] <alex-weej> geser: no
[19:04] <alex-weej> i've installed it
[19:04] <alex-weej> what do i do with it?
[19:05] <geser> rebuild again
[19:05] <geser> it replaces dh_strip (?) to strip out the debug symbols into it's own ddeb
[19:05] <alex-weej> oi
[19:05] <alex-weej> *oic
[19:06] <alex-weej> i'm trying to figure out why gnome-session hangs most of the time from gdm
[19:06] <alex-weej> in hardy
[19:07] <alex-weej> geser: so how do i install the symbols?
[19:07] <alex-weej> or do they just go into the regular packages?
[19:07] <alex-weej> ah wait i see all these "ddeb" files
[19:08] <geser> alex-weej: install the ddebs like normal debs
[19:08] <geser> e.g. with dpkg -i
[19:09] <alex-weej> done thanks
[19:11] <alex-weej> does anyone know what happened to VT switching?
[19:11] <Keybuk> -v
[19:12] <alex-weej> has it been disabled for a reason? GDM doesn't respond to the key combos and when doing it from a GNOME session the screen blanks for a second then dumps you back into X
[19:15] <soren> slangasek: Yes?
[19:16] <soren> alex-weej: iz consolekit bug.
[19:16] <alex-weej> soren: https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/175682
[19:16] <ubotu> Launchpad bug 175682 in gdm "GNOME rarely starts from GDM in Hardy" [Undecided,New]
[19:16] <alex-weej> soren: check the stack trace, sure?
[19:16] <Keybuk> alex-weej: not that I'm aware
[19:16] <alex-weej> soren: oh wait, you're talking about VT-switching
[19:16] <Keybuk> alex-weej: I've seen it fail a few times, and done C-A-F1 thru F6 and one of them works along the way
[19:16] <alex-weej> sorry
[19:16] <soren> alex-weej: Yes, I am. :)
[19:16] <Keybuk> soren: how does console kit break that?
[19:17] <alex-weej> VT-switching hasn't worked for years for me
[19:17] <soren> Keybuk: Yes. Something about X and ConsoleKit fighting over it.
[19:17] <alex-weej> on any of the 3 ubuntu machines i run!
[19:17] <Keybuk> years = not a known bug
[19:17] <soren> Keybuk: Ian fixed it in gutsy, but his patch was dropped in the merge, apparantly.
[19:18] <slangasek> soren: "pong"
[19:19] <soren> slangasek: Oh, did I ping you?
[19:19] <slangasek> soren: you asked me if I was around at 6am :)
[19:20] <soren> slangasek: Oh, right.
[19:20] <soren> Hm...
[19:21] <soren> slangasek: I completely forgot what I wanted. Probably something about your keepalived merge, I'm not sure what.
[19:21] <soren> I'll ask again, if I think of it :) I got to run now, sorry.
[19:23] <slangasek> ok, later
[19:35] <geser> bddebian: can prelink get synced or got the ubuntu changes lost in the last merge? see http://patches.ubuntu.com/p/prelink/prelink_0.0.20061201-1ubuntu1.patch
[19:57] <bddebian> geser: Yikes, I must have dropped a patch in there somewhere :(
[20:12] <super-6-1> hello im having troble with my apperance
[20:12] <super-6-1> in Visual Effects it stays normal and when i change it, it changes itself back to normal
[20:27] <geser> pitti: is it planned to import NEW packages from Debian once again before DIF?
[20:27] <pitti> geser: hm, I just did so yesterday
[20:28] <pitti> geser: but requests for importing them continue to be valid until FF
[20:31] <geser> sorry, my error, I should have used the source package name instead of the binary one to check if it's already imported
[20:32] <alex-weej> pitti: ddebs for hardy?
[20:32] <pitti> alex-weej: yes?
[20:33] <alex-weej> is there an uptodate repo?
[20:33] <pitti> alex-weej: something wrong with http://ddebs.ubuntu.com/ ?
[20:33] <pitti> it's supposed to be ok
[20:33] <alex-weej> yeah. i tried to install libgnome-keyring0-dbgsym from it but it wanted to install an old version of libgnome-keyring-0 as a dependency
[20:34] <alex-weej> 2.20.something i believe
[20:34] <alex-weej> when we're using 2.21 in hardy now
[20:34] <Fujitsu> It hasn't updated since the end of last month.
[20:34]  * pitti checks
[20:34] <pitti> argh
[20:34] <alex-weej> are you OK?
[20:34] <pitti> 1004      8859  0.0  0.0   5144  2300 ?        S    Nov30   0:07 apt-ftparchive generate /
[20:34] <alex-weej> do you want us to send help?
[20:35] <pitti> WTH?
[20:35]  * Fujitsu agrees with pitti.
[20:36] <Fujitsu> strace it and see wth. it's doing?
[20:37]  * pitti goes to rescue the ddebs from the last 7 days; anything older is lost
[20:38]  * Fujitsu hopes there were no important libraries uploaded during those 5 days.
[20:39] <alex-weej> so what's happened?
[20:39] <pitti> I think I lost my ssh connection, and it was spinning on getting the tty back, or so
[20:40] <pitti> that was around the day when we moved ddebs to a new server
[20:40] <pitti> alex-weej: thanks for the poke
[20:40] <Fujitsu> Ahh.
[20:40] <alex-weej> ok cool no problem
[20:52] <geser> pitti: have you some time to sponsor #174749 so graphviz can leave depwait?
[20:53] <pitti> alex-weej: ok, ddebs.u.c. has latest gnome-keyring ddebs now; not indexed yet, though
[20:53] <alex-weej> pitti: i ended up building them myself, but thanks anyway
[20:54] <alex-weej> by the way, is there some easy way to automatically pull debugging symbols when using GDB yet? :D
[20:54] <alex-weej> i always have to use a pretty laborious iterative process when trying to view a stack trace properly
[20:54] <pitti> alex-weej: man apport-retrace(1), it has a -g option to kick you into gdb
[20:55] <alex-weej> alex@flash:~/Videos/Phone/7$ man apport-retrace
[20:55] <alex-weej> No manual entry for apport-retrace
[20:55] <alex-weej> alex@flash:~/Videos/Phone/7$ man apport-retrace(1)
[20:55] <alex-weej> bash: syntax error near unexpected token `('
[20:55] <pitti> alex-weej: you need to install apport-retarce
[20:55] <pitti> retrace, even
[20:55] <alex-weej> is this what most people do then?
[20:56] <alex-weej> actually, what if i don't have a dump?
[20:56] <alex-weej> as in, my program is still running
[20:57] <pitti> alex-weej: hm, I should teach apport-retrace about this use case (attach to pid instead of apport crash report)
[20:57] <alex-weej> that would be pretty sweet
[20:57] <pitti> wishlist bug report appreciated :)
[20:58]  * lamont sticks kde/hppa back in the cellar
[20:58] <pitti> geser: doing
[20:58] <geser> pitti: thanks
[20:59] <ScottK> lamont: Did you get my mail with the pinentry merge?
[20:59] <pitti> geser: will just take a while, my network is sooooo sloooooow tonight
[20:59] <lamont> yeah
[20:59] <lamont> off to a meeting that starts in 30 seconds, and then after that I'll finish playing with it and upload
[21:00] <ScottK> lamont: Cool.  Did you see/like my comment on the bug complaining about lack of IDN support in BIND?
[21:00] <ScottK> K.  See you later.
[21:00] <lamont> will have to look... LP?
[21:00] <geser> pitti: I already wait a half week for a sponsor so some more hours don't matter
[21:00] <lamont> or debbugs?
[21:00] <pitti> 5130B/s -- *sniff*
[21:00] <Riddell> pitti: did you look at that hal issue?
[21:00] <lamont> pitti: what's up with that?  you trying to compete with my link?
[21:01] <pitti> Riddell: high on my list, promised
[21:01] <ScottK> lamont: It was LP, but it was simple enough.  I just opined that perhaps lack of IDN domain name support was a security feature.
[21:01] <lamont> lol
[21:01] <lamont> and gone
[21:01] <geser> lamont: what's the status of hppa for hardy? should we start looking at FTBFS on hppa or can we still ignore them?
[21:02] <ScottK> geser: Last FTBFS mail on hppa I got it seemed some pretty basic things were left unbuilt.  I think it's probably premature.
[21:04] <geser> pitti: can you also sponsor my scons merge (bug #157668)? Hobbsee doesn't want sponsor it again
[21:04] <ubotu> Launchpad bug 157668 in scons "[Merge] scons 0.97.0d20071203-1ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/157668
[21:04] <pitti> EBANDWIDTH
[21:05] <pitti> (both mental and net), sorry
[21:05] <pitti> geser: please assign it to me and set it to 'in progress', I'll do it tomorrow
[21:05] <geser> pitti: both?
[21:05] <pitti> geser: scons
[21:06] <geser> pitti: thanks
[21:07] <pitti> geser: graphviz uploaded, thank you
[21:19] <alex-weej> does network manager come on server installations?
[22:18] <keescook> why, when I attempt to install libopenexr2ldbl, does apt want to remove all things kde?
[22:18] <jpatrick> it's a transition in process
[22:18] <keescook> ah -- are things still building?
[22:19] <jpatrick> yep
[22:19] <Riddell> keescook: most kde 3 packages should be through the transition now
[22:21]  * keescook holds on to his hat
[22:42] <lamont> geser: hardy/hppa: if it's main, and not java, it warrants looking into.  there are still 1600 packages unbuilt in universe
[22:42] <lamont> OTOH, we're heading over 80% any time now.
[22:43] <lamont> 2007/345/22 98.1518 96.244 96.317 79.5279 95.6973 94.9352 96.7182
[22:43] <lamont> hppa is the 79.5... too lazy go to get the list. ;-)
[22:43] <lamont> see http://bld-4.mmjgroup.com/~wb/buildLogs/stats/hardy2-short.png
[22:43] <slangasek> lamont: so is someone working on the java bootstrap?
[22:44] <lamont> slangasek: boku
[22:44] <lamont> OTOH, I need to hack together something that fakes up enough of gjdoc in order to build gcj-4.2 so that I can build gjdoc so that I can build gcj-4.2 :-(
[22:44] <geser> lamont: I ask because hppa has the most red cells in http://qa.ubuntuwire.com/ftbfs/
[22:44] <lamont> tonight I'll work on the script to touch an output file.
[22:45] <lamont> geser: i expect so.
[22:45] <lamont> once hppa finishes getting through the queue, I plan to have a mass-giveback done.
[22:45] <lamont> ScottK: so you're sure about pinentry, eh?
[22:49] <slangasek> lamont: ok. so the patches to drop db.*-java on hppa will go away in the hardy timeframe? :)
[22:49] <lamont> slangasek: that is certainly the goal
[22:49] <slangasek> \o/
[22:49] <lamont> and yes, I know that's not an answer. :-)
[22:51]  * lamont uploads pinentry for ScottK 
[22:57] <Lutin> does someone have a minute to look at bug #173717 ?
[22:57] <ubotu> Launchpad bug 173717 in grub "Grub has a build-depends-indep against a multiverse package" [High,New] https://launchpad.net/bugs/173717
[23:19] <ScottK> lamont: Thanks.
[23:20] <ScottK> lamont: I'm sure you left changed by unmodified so whatever I messed up will stick to me and I'll fix.
[23:26]  * ScottK head-desk (forgot the -v when building the source package again).  Urgh.
[23:40] <YokoZar> Is Hardy going to default to GCC 4.2 (or newer?)  I recently uncovered a Wine bug related to using 4.1
[23:41] <ScottK> YokoZar: I understand you've got a WINE package for Hardy up on REVU.  Is it the current release?
[23:41] <ScottK> YokoZar: Please fix it anyway so it'll work when we backport to Gutsy.
[23:41] <YokoZar> ScottK: Almost.  I need to change the GCC version in it
[23:41] <ScottK> OK.
[23:42] <YokoZar> Speaking of which, I'm running into a problem with that
[23:42] <ScottK> YokoZar: Ping me when you think it's ready.
[23:42] <ScottK> OK.