[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<EMAIL_ADDRESS>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<EMAIL_ADDRESS>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<EMAIL_ADDRESS>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<EMAIL_ADDRESS>[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.


[22:48] <techbw> looks like I may run into problems then? think I will image the drive before the upgrade just in case
[22:48] <NightWlkr> yes u can pidus..
[22:48] <pidus> NightWlkr: and how?
[22:49] <techbw> hope there will be better support for SiS in the future however I am doubtfull it will be in the near future
[22:49] <NightWlkr> techbw: me too, but instead of waiting i rather buy a decent vga since that's cheap nowadays
[22:49] <techbw> apt-get install ubuntu-desktop i think it is
[22:50] <pidus> techbw: ok thanks
[22:50] <techbw> don't really have that option, as I am on laptop
[22:50] <NightWlkr> then stick with kde3.5 for now as an advice..i may switch too but had a problem installing yakuake :P
[22:51] <bdizzle> hey
[22:51] <techbw> pidus: that is correct sudo apt-get install ubuntu-desktop
[22:51] <bdizzle> does anyone know anything about KDevelop?
[22:51] <bdizzle> I'm trying to use it for a programming class I have and am having some difficulty getting it to run properly
[22:52] <techbw> I will give it a go once I have found a utility to image the drive, Ghost4Linux looks quite complicated.
[22:52] <pidus> techbw: cool
[22:52] <techbw> does not look as easy as Symantecs Ghost.
[22:52] <NightWlkr> well i used to have a bootable cd called partition expert..should do the trick
[22:52] <techbw> will check that out.
[22:53] <NightWlkr> i think it's paid though..had to steal a copy back then :P
[22:53] <NightWlkr> but if u can get it it's quite easy
[22:54] <techbw> KDE4 looks really cool, hope I don't run into any issues, I can live without the compiz stuff, although it would have been nice if there was support for SiS cards in 8.10
[22:54] <bdizzle> techbw: I have problems with KDE4 still
[22:54] <techbw> what problem you having?
[22:54] <bdizzle> mostly that it randomly closes firefox and I have some mouse / video issues
[22:54] <live_to_code> no compiz in kde4 (compiz is optional) kwin composite does nicely
[22:54] <NightWlkr> techbw: what seems cool there won't run on sis :P
[22:55] <NightWlkr> even kwin gave me a white screen i could work with nothing
[22:55] <bdizzle> does anyone know anything about KDevelop?
[22:55] <bdizzle> if not, does anyone know of a channel I can go to for help?
[22:55] <techbw> no I have a desktop as well with Nvidia
[22:55] <NightWlkr> from what i heard it had problems with nvidia aswell?
[22:56] <bdizzle> yes
[22:56] <techbw> bdizzle: don't think I am the one to help there, have not even upgraded to KDE4 yet
[22:56] <NightWlkr> weird..most ppl use nvidia
[22:56] <bdizzle> I know, I was just saying where I was having problems
[22:56] <live_to_code> i'm running ati hd 2400 and it runs perfectly. i have to install 8.10 in text mode though as live cd don't wanna play.
[22:56] <techbw> It does, but once you get past the install, you can install prop. drivers.
[22:57] <live_to_code> then i get a text login where i manually update, then it runs
[22:57] <techbw> basically the install has to be done with safe graphics mode, because of licence issues, it's about not having end user licence during install process go figure
[22:58] <NightWlkr> ya same thing for amarok not having mp3 support..but u can install it later on :P
[22:58] <live_to_code> yeah, that's normal though
[22:59] <bdizzle> GRRRR
[22:59] <techbw> From what I heard is that once the install is done, on first boot, you will have a popup window asking to install the drivers, and you have to agree to eula
[23:00] <NightWlkr> well they can add the eula b4 the install and make it work..i don't find any complications there
[23:00] <Neremor> hello!
[23:00] <Neremor> i need some help with grep
[23:00] <NightWlkr> but i won't have problems with ati vga's.. i can run the install with my sis built in and then install the ATI
[23:01] <techbw> I don't either but apparently Conical don't want eula in the install process, as it is not opensource, and they want to adhere to the GPL
[23:01] <techbw> something to that effect
[23:01] <Neremor> i'm currently creating a script that should read out all birthdays on a page. for the readout i want to use grep.
[23:01] <Neremor> the format is like that:
[23:01] <Neremor> Birthday:{{tabulator}}22.03.1972
[23:02] <techbw> you shouldn't have an issue if you install using sis and after that install your ati card.
[23:02] <Neremor> what should the grep command look like? i want to have the date (22.03.1972) as the output of the command afterwards
[23:02] <NightWlkr> no i won't..but i have an issue with my ati vga..using windows i kicked my pc a few times now it won't work :P
[23:02] <techbw> Neremor: I think that would be to do with programming, this is the Kubuntu support room
[23:02] <Neremor> hm
[23:03] <Neremor> i'm talking about an linux program, whats wrong about that?
[23:03] <etfb> Can someone with KDE4 in Intrepid look in their System Settings for me, and tell me if you have an icon for Multimedia?  Mine isn't there, and as an interesting coincidence, my audio doesn't work.
[23:03] <NightWlkr> etfb: maybe u don't have a sound card driver installed
[23:04] <etfb> NightWlkr: I believe I do, but how do I tell?
[23:04] <techbw> Neremor: nothing wrong, but you would have better success in a programming room, rather than a support room, didn't mean anything by that
[23:04] <NightWlkr> u should check ur system u have 2 choices...command line or graphical
[23:05] <etfb> NightWlkr: Prefer command line; it's quicker and then I can use history.
[23:05] <NightWlkr> command line i think u can tell by dmesg |grep sdb
[23:05] <techbw> Nightwlkr: would that not bring up info on sdb hard drive?
[23:06] <etfb> NightWlkr: I assume that's a typo and you meant grep snd?
[23:06] <NightWlkr> yup sorry checking the sound :S
[23:07] <techbw> ;-)
[23:07] <etfb> Damn... how do you set case-insensitive search mode in less?
[23:08] <etfb> Ah!  dash i
[23:08] <etfb> OK, nothing in dmesg about "sound", "snd" or "alsa"
[23:09] <techbw> i get no return either and my snd is working
[23:09] <techbw> i even tried pcm and still no return
[23:10] <NightWlkr> well u can always install device manager as a graphical interface :$
[23:10] <NightWlkr> i can't find sound in dmesg either
[23:10] <techbw> i do get for dmesg | grep ac97 though
[23:10] <techbw> wich is my snd card
[23:10] <techbw> what does lspci say, do you see snd card in list
[23:11] <etfb> NightWlkr: aplay -l says I have an ALC889 Analog
[23:11] <mefisto__> try this: lspci |grep -i audio
[23:12] <techbw> then try dmseg | grep ALC889
[23:12] <mefisto__> or this: asoundconf list
[23:12] <etfb> Names of available sound cards: Intel
[23:12] <techbw> ooo learnt somthing new...got respons on that command
[23:12] <etfb> Impressive!  (Not)
[23:13] <etfb> (The results of the command, not the command itself...)
[23:13] <NightWlkr> me too techbw
[23:13] <etfb> Tried dmesg | grep -i ALC and got nothing relevant.
[23:14] <mefisto__> what about lspci | grep -i audio  ?
[23:14]  * etfb is unsurprised to find that lscpi doesn't exist. Who would want to list the Consumer Price Index? lspci works, though.
[23:15] <techbw> why is it grep and not grab??? cos what the command is actually doing is grabbing that info out of a list??
[23:15] <techbw> is alsa installed on your system?
[23:15] <stdin_> techbw: the name is taken from the first letters in global / regular expression / print
[23:15] <etfb> techbw: Ancient Unix lore: grep = global [regular expression] print in a very old Unix editor, ie you would type gh.ll.+w.rld[ENTER]p or something like that
[23:16] <techbw> ah!
[23:16] <techbw> acronym
[23:16] <etfb> No, TECO command.  Same thing, orders of magnitude different pain levels.
[23:16] <stdin_> most old unix commands are
[23:16] <techbw> damn lucky i did not use unix then, cos I would have thrown out the window with commands like that
[23:16] <etfb> stdin_: Someone told me once that Unix was written originally in Dutch, and I believed it.  I'm not sure I ever stopped.
[23:17] <mefisto__> what's the "global" refer to?
[23:17] <etfb> mefisto__: Repeat through the entire file, ie not just on the current line.
[23:18] <etfb> Regarding lspci | grep -i audio, I get one line, referring to an 82801H HD Audio Controller
[23:18] <stdin_> mefisto__: global search, rather than a local/bounded search
[23:19] <techbw> we now know the sound card exists, but can we help in getting the thing to work, I know I can't :-P
[23:20] <techbw> thanks for the lesson guys, learned a new command, and a little on history of grep, but I am off now, cheers all
[23:21] <etfb> So the sound card is an ALC889, right?  So what's this 82801C thing?
[23:21] <phil_> cya
[23:21] <live_to_code>  /msg NickServ identify cepfxfyr
[23:22] <stdin_> password change time
[23:22] <live_to_code> lol
[23:22] <NightWlkr> https://bugs.launchpad.net/ubuntu/+bug/122560
[23:22] <live_to_code> aye
[23:22] <NightWlkr> etfb: this is what u'r going through
[23:23] <etfb> live_to_code: Excellent password, though.  Very secure.  Just need to avoid spaces at the start of your / lines.
[23:23] <live_to_code> hahaha
[23:24] <jussi01> should always do that in the server window..
[23:24] <NightWlkr> etfb: there r 5 patches there that worked with some ppl should i just paste the links for u?
[23:24] <etfb> NightWlkr: That's fine, I'll read and digest.
[23:26] <live_to_code> @ jussi01: normally would, i panicked! lol
[23:26] <jussi01> :)
[23:26] <stdin> you can set most clients to auto-identify to nickserv, and with freenode you can use your nickserv password as the server password for automatic identification
[23:30] <marcel> what is libncurses ?
[23:31] <etfb> marcel: A library that allows programmers to write stuff that uses the terminal for simple DOS-style layouts.  Have a look at, say, alsamixer for the sort of thing it allows.
[23:31] <etfb> marcel: Good for doing a user interface without messing about with X, KDE, GTK, etc.
[23:32] <marcel> thank you verry much etfb:
[23:32] <etfb> marcel: Out of interest: why do you ask?
[23:32] <marcel> how can i use libncurses ?
[23:32] <etfb> It's a rewrite of the curses library, so google for that.
[23:33] <marcel> my interest is to write the function getch(); /* get a char withou echo */  -- into "C"...
[23:34] <marcel> getch(); -- not exist into gnu c library...
[23:34] <marcel> and i need a getch(); function
[23:38] <etfb> marcel: the ncurses library will have that as a built-in, I expect, so it won't be hard to find.
[23:38] <cjae> !update
[23:38] <stdin> marcel: getch() is a windoes command, use getchar()
[23:39] <stdin> *windows API function
[23:39] <etfb> (Dang it... what's the IRC command to undo an /away?)
[23:39] <stdin> /back
[23:40] <etfb> Excellent.  Thanks.
[23:40] <stdin> clients should accept '/away' as back, but some don't
[23:40] <etfb> Out of interest, how did you manage to type /back on a line by itself and not have it executed?
[23:40] <stdin> //back
[23:40] <stdin> the client will remove the 1st slash
[23:40] <etfb> stdin: Obvious.  Pardon me while I slap myself for not guessing that.
[23:40]  * etfb slaps /me
[23:41] <marcel> hard to find ncurses with headers
[23:41] <stdin> marcel: you don't want ncurses for simple console apps
[23:41] <marcel> thank you
[23:42] <stdin> just use int getchar(void)
[23:42] <stdin> or int getc(FILE *stream)
[23:42] <marcel> getchar(); // ends with a '\r' char and i don't want that
[23:43] <marcel> just to simulate a getch(); function !!
[23:43] <stdin> getchar() reads what ever is in the buffer
[23:43] <marcel> yes
[23:43] <stdin> a better place to ask about this is in ##c
[23:43] <marcel> i ask and they tell me abou ncurses
[23:44] <cjae> !amd
[23:44] <marcel> i don't know how to obtain ncurses..., :)
[23:44] <stdin> libncurses5-dev
[23:44] <mister-tea-lapto> so install liibncurses5 through synaptic
[23:44] <marcel> thank you
[23:45] <stdin> you'll want the -dev for the headers
[23:45] <marcel> yes
[23:45] <marcel> thank you again
[23:46] <stdin> and you'll need to -lncurses
[23:47] <stdin> btw, there is getline() in <stdio.h>
[23:47] <stdin> you'll have to #define _GNU_SOURCE to use it
[23:51] <cjae> is there a prblem with ati chipset in linux?
[23:52] <cjae> I have no ethernet internet
[23:53] <cjae> and its a realtek onboard so it shouldn't be problem
[23:56] <Papfox> Hi, I'm having graphics performance issues with KDE4 on a machine that really shouldn't be having trouble (Dell Precision M6300 laptop - 2.4G dual core, 4GB RAM, nVidia Quadro FX1600m 256MB GPU [nVidia 177 binary blob], 1920x1200 panel, 7200RPM SATA drive). There are three things going wrong: 1) When I open new apps the windows show corrupt "stripey" contents from elsewhere on the screen. 2) When I scroll in apps like Firefox if the machine
[23:56] <Papfox> is busy the psrt of the window that got scrolled contains an a duplicate of an adjacent stripe which goes away when I open a menu. 3) Mouseovering files (particularly in dolphin on konqueror) causes GUIs of other programs (particularly xmms) to become jerky [on FC9 and 10 it also made pulseaudio glitch] Sorry for such a long post. Thanks for your help.
[23:58] <Papfox> Machine performed like a racehorse on Hardy with KDE3
[23:59] <dsnaike> Papfox what kde ver. 4.x


[00:25] <cmaloney> Evening
[00:27] <rick_h_> party
[17:48] <jrwren> .np evarlast
[17:48] <bookiebot> evarlast's current track - Void by Ringtailed Snorter on There Is No Time (disc 3)
[17:48] <jrwren> PARTY!
[17:48] <rick_h_> lol
[17:58] <cmaloney> .np squeekyhoho
[17:58] <bookiebot> squeekyhoho's current track - Your Truth by Imperative Reaction on Redemption
[18:55] <jrwren> this is so weird.
[18:56] <jrwren> i want dch on macosx
[18:56] <jrwren> cuz its "just" python, but often I want to dch -i
[18:56] <jrwren> so that our build server will automatically cut a new package
[19:02] <mrgoodcat> ¯\_(ツ)_/¯
[19:07] <cmaloney> .np squeekyhoho
[19:07] <bookiebot> squeekyhoho's last track - Watching Over You (Implant remix) by Solitary Experiments on Cause and Effect CDM [21 May 2014, 18:47]
[19:08] <cmaloney> .np squeekyhoho
[19:08] <bookiebot> squeekyhoho's last track - Watching Over You (Implant remix) by Solitary Experiments on Cause and Effect CDM [21 May 2014, 18:47]
[19:08] <cmaloney> dammit
[19:10] <mrgoodcat> not scrobbling properly?
[19:10] <cmaloney> .np squeekyhoho
[19:10] <bookiebot> squeekyhoho's last track - Watching Over You (Implant remix) by Solitary Experiments on Cause and Effect CDM [21 May 2014, 18:47]
[19:11] <cmaloney> yeah, though that's last.fm
[19:11] <cmaloney> Ah well
[19:12] <cmaloney> https://www.youtube.com/watch?v=6HMh15h8DWg&feature=kp
[19:12] <bookiebot> http://goo.gl/M2P32b - Stromkern-Slow cascade - YouTube
[19:12] <cmaloney> That was what I was trying to share.
[19:19] <cmaloney> And when it rains...
[19:19] <cmaloney> dad-in-law is going to the hospital. Not sure if he's having an alergic reaction to cough medicine.
[19:19] <brousch> ah geez
[19:20] <cmaloney> yep
[20:54] <cmaloney> Hanging out at Beaumont. :)
[21:01] <jrwren> ooooo stromkern.
[21:01] <jrwren> nice guy
[21:10] <cmaloney> Yeah


[11:20] <cpaelzer> smoser: already around?
[12:18] <cpaelzer> smoser: while the former two quesitons are solved by time, I would still ahve another if you are around
[13:22] <smoser> cpaelzer, here now.
[13:22] <smoser> what sup?
[13:23] <cpaelzer> hiho
[13:23] <cpaelzer> I'm testing more nd more regarding the cloud-init issue you reported due to my merge
[13:23] <cpaelzer> most things are done, I found a few on top thou
[13:23] <cpaelzer> working on these, but that was not the question
[13:23] <cpaelzer> at some point I'll have to throw it into a adt or ppa to test if it works there as well
[13:24] <cpaelzer> since packaging isn't in the repo's itself I wondered what the recommended way is to do so
[13:24] <cpaelzer> I mean there are many ways
[13:24] <cpaelzer> pull-lp-source - merge a bzr tree in
[13:24] <cpaelzer> bzr tree and merge a debian dir into that
[13:24] <cpaelzer> or something totally different
[13:24] <cpaelzer> I assume you don't do that manually each timne, so I wanted to know which way I should go to test ppa/adt builds
[13:25] <cpaelzer> smoser: ^^
[13:25] <smoser> cpaelzer, right. need to test building in ppa.
[13:26] <smoser>  ./packages/bddeb
[13:26] <smoser> it hsa --help, but largely i'd run:
[13:26] <smoser>  ./packages/bddeb -S
[13:26] <smoser> then
[13:26] <smoser>  sbuild ...
[13:27] <cpaelzer>   /packages/bddeb -S gievs a .dsc and a orig tarball then?
[13:27]  * cpaelzer is reading bddeb ...
[13:27] <smoser> yeah, it uses bzr export to get a .orig and then goes from there.
[13:28] <cpaelzer> ok nice, then I can hit these stages once I fixed a corner case of the keyserver issues
[13:28] <cpaelzer> smoser: btw I also made sure I port fixes I did this way between curtin/cloud-init as I work on the same code for both
[13:28] <cpaelzer> so I hope to end the day with an update to the curtin MP and a new cloud-init MP
[13:29] <smoser> ok. great.
[13:50] <GivenToCode> hi i have a custom cfg in /etc/cloud/cloud.cfg.d that specifies an fs_setup to mkfs ext4 on ephemeral0 (ec2), however on c3 instances types we get an error in the log that /dev/xvdb is already mounted when trying to mkfs...
[13:50] <GivenToCode> this is 0.7.5-0ubuntu1.18
[13:51] <GivenToCode> I would expect fs_setup to run before any mounting, right?
[13:52] <GivenToCode> there is an entry for xvdb in fstab, and I've tried to override that by specifying a mounts [ ephemeral0, null ]
[14:11] <cpaelzer> GivenToCode: yes it should set up fs_setup things before the mount step of cloud-init
[14:11] <cpaelzer> GivenToCode: but I'd wonder if something else could mount it even before
[14:11] <cpaelzer> GivenToCode: depending on you influence to this environemnt you could add in your .cfg commant to check the status early on
[14:12] <cpaelzer> GivenToCode: like early_commands: checkmounts: 'mount'
[14:13] <cpaelzer> and then check that output if it really is mounted at the beginning
[14:14] <cpaelzer> cpaelzer: sorry I'm mixing up things here - let me rethink
[14:14] <cpaelzer> writing too muhc curtin / cloud-init code at the same time - that would have been the curtin answer
[14:15] <cpaelzer> GivenToCode: doc/examples/cloud-config-boot-cmds.txt should be better
[14:17] <cpaelzer> GivenToCode: if you prefer an url http://cloudinit.readthedocs.io/en/latest/topics/examples.html#run-commands-on-first-boot
[14:49] <cpaelzer> smoser: did the mirrorlist issues (the last one you added the skipif for) happen to you in sbuild as well, or only in the buildd's?
[14:50] <smoser> cpaelzer, no. only in a buildd
[14:50] <smoser> cpaelzer, but think about it working on centos
[14:50] <cpaelzer> smoser: k, thx - setting up a victim ppa then
[14:50] <smoser> we want unit tests to work there.
[14:50] <cpaelzer> smoser: I already have
[14:50] <smoser> ok.
[14:50] <smoser> i maeant to tell you this...
[14:50] <smoser> there is a 'FilesystemMocking' class
[14:50] <smoser> or somethignt
[14:50] <cpaelzer> smoser: I already covered that - at least I think so :-)
[14:51] <smoser> aht basically mocks all fsreads.
[14:51] <smoser> to another directory that you can popoulate
[14:51] <cpaelzer> smoser: for this in particular it doesn't need a fs mocking class
[14:51] <smoser> ok. thats fine.
[14:51] <cpaelzer> the feature of influencing apt environment is very very ubuntu/debian specific
[14:51] <cpaelzer> so are the tests
[14:51] <cpaelzer> but that can be nicely done with a skipIF to the apt binary
[14:52] <cpaelzer> I covered this and more and you can take a look once it is mature enough for a merge proposal
[14:52] <cpaelzer> for now I seem to uncover further issues faster than I like and EOD is coming closer ...
[14:52] <cpaelzer> :-/
[14:53] <smoser> cpaelzer, i dont know..
[14:53] <smoser> it is in fact debian/ubuntu specific
[14:53] <smoser> but that does not mean the unit tests should not run elsewhere.
[14:54] <cpaelzer> for the start I'd like to disable things so they work properly
[14:55] <cpaelzer> over time one can (r not) commit the time to enable this on more environments
[14:55] <cpaelzer> that is what I'd prefer
[14:55] <cpaelzer> I feel to postpone too much as I try to get this done - so I wouldn't add a centos env test to the task list right now
[14:56] <cpaelzer> but you are right overall - you want a centos dev on cloudinit to see when he breaks things
[14:56] <smoser> well, thats fine. but generally speaking the failure i saw was from either a file existing or not existing (or a directory or something)
[14:56] <smoser> i'm not really sure
[14:56] <smoser> and the fact that that exists or does not exist is somethign that would ideally be covered by the unit test
[14:56] <smoser> which should not require the system its running on to be in a given state
[14:57] <cpaelzer> ah that one - it is a file delivered by cloud-init itself, and we don't check if the file exists
[14:57] <cpaelzer> we check if cloud-init "checks" if the file exists
[14:57] <cpaelzer> because that is the code path that it should take and that is what the unit test does
[14:57] <cpaelzer> the file doesn't exist on my system either
[14:57] <cpaelzer> but the test works
[14:58] <cpaelzer> what happens there is the issue in find_apt_mirror_info that I need to debug in the ppa environment, because I can't see locally what is breaking
[14:58] <cpaelzer> an issue in that function causes the one you have seen as follow on error
[14:58] <smoser> right. there is a build logo from an existing one if you wantd.
[14:58] <cpaelzer> I have checked the two logs you linked
[14:59] <smoser> yah. ok.
[14:59] <cpaelzer> but I need more debug data on it
[14:59] <smoser> you're doing well,. sorry to sound like i'm giving you flack
[14:59] <cpaelzer> for now I'm unhappy wit hthe gpg key things - I wanted to fix them right
[14:59] <smoser> you wrote a bunch of test cases for stuff that wasnt' tested and fixed a bunch of stuff and there was fallout
[14:59] <smoser> the first part is +100
[14:59] <smoser> )
[14:59] <cpaelzer> I'm fine and we will make it good :-)
[14:59] <cpaelzer> thanks
[14:59] <smoser> the second part is admittedly *my* fault and cloud-init fault for accepting your MP before it built in a ppa
[14:59] <smoser> :)
[14:59] <cpaelzer> so I added a nice fallback in case network is unavailable - but it will use real network if it is available
[15:00] <cpaelzer> unfortunately now that is "can" work it complains in sbuild envs for things that are not writable
[15:00] <cpaelzer> will get it done ...
[15:00] <smoser> please dont depend on presense of a keyserver
[15:00] <cpaelzer> just gets a longer and longer task :-)
[15:00] <smoser> those things really suck
[15:00] <cpaelzer> smoser: thats what I ment - I don't DEPEND anymore, but IF I can reach it properly I do
[15:00] <smoser> that will cause arbitrary failures
[15:00] <cpaelzer> and if I can't reach it, it has a fallback that works
[15:01] <cpaelzer> so the test is happy with and without keyserver
[15:01] <cpaelzer> it even works with broken keyservers or random dns names
[15:01] <cpaelzer> but IF it works it just is closer to the real thing
[15:01] <cpaelzer> which isn't bad for a unit test
[15:01] <smoser> i was honestly fairly OK with not unit testing that shell blob. and prefer that to cloud-init's unit tests mucking with my .gpg dir
[15:02] <cpaelzer> hehe
[15:02] <cpaelzer> it isn't a shell blob anymore
[15:02] <cpaelzer> :-)
[15:02] <smoser> ok. but i still would really rather it not ever modify my .gpg dir
[15:02] <cpaelzer> thatr with the .gpg dir is what I have to tackle next
[15:02] <cpaelzer> for sbuild env anyway
[15:02] <cpaelzer> smoser: so you tihnk it is ok to throw parts away and mock that side of things?
[15:03] <cpaelzer> ok, I can do that - that will throw away some code that cost me some sweat today, but it was good for the learning still
[15:06] <cpaelzer> at least we got the shell blob to become python as you wanted as well, thanks to a nice suggestion of rharper and some polishing I did
[15:07] <rharper> cpaelzer: nice
[15:07] <cpaelzer> I think with the plan to not mess around with .gpg at all in the tests I won't complete it today anyway
[15:07] <cpaelzer> smoser: do you mind if it is tomorrow and not today that you get the next MP revision?
[15:07] <rharper> yeah, I'd be very dubious of relying on a .gpg dir
[15:08] <rharper> rather a tmpdir and export GPG var to point to it
[15:08] <rharper> certainly GPG will check ENV for that location
[15:08] <cpaelzer> rharper: it has an argument
[15:08] <cpaelzer> rharper: just need to find a way to insert that into the subp's
[15:08] <cpaelzer> I still want to test the original code and not mock it all
[15:09] <rharper> sure, lemme see if I've example of setting env for subp
[15:09] <smoser> you can just mock the output of gpg
[15:09] <smoser> capture that call really is i think the right way to do it.
[15:10] <cpaelzer> I'd mock the gpg calls but then assert on them to make sure they were poked the right way
[15:10] <smoser> honestly, mocking the call to that shell blob as i did, we have 2 lines of untested code out of that.
[15:10] <smoser> and no mucking with your .gpg
[15:10] <cpaelzer> mucking vs mocking :-P
[15:10] <smoser> for code that hasnt changed and worked fine for 4 years (except for arguably invalid user input)
[15:11] <smoser> basically, i dont want you to spend a bunch of time making sure we get test coverage on that.
[15:11] <cpaelzer> ok
[15:11] <cpaelzer> I'll try to mock it then and get it working tomorrow
[15:12] <rharper> cpaelzer: Popen takes a env= param; that's not exposed in subp IIRC, but one could,  then myenv = os.environ_copy(), and myenv[VAR]=VAL , pass env=myenv;
[15:12] <cpaelzer> rharper: thanks for checking, but given the requirements - for now - I'd go with smoser and "just" mock some things
[15:12] <rharper> yep
[15:14] <smoser> subp takes env also.
[15:14] <smoser> yeah.
[15:24] <rharper> nice
[15:24] <GivenToCode> cpaelzer, yes something is mounting everything in fstab before fs_setup, we don't have anything custom running before cloud-init
[15:38] <GivenToCode> ok, i think the fix is to remove it from fstab when we bake the image
[15:59] <ajorg> smoser: Can I submit GitHub pull requests instead of bzr branches for contributions?
[16:02] <smoser> ajorg, wont be github pull requests. but launchpad git pull requests should be shortly.
[16:02] <smoser> ajorg, basically upstream code path will still be launchpad but revision control in git
[16:02] <ajorg> okay, I'll try to learn bzr for today and maybe leave some of our more interesting patches for when git is available.
[16:08] <ajorg> If I did a terrible job of preparing this, it would be good to correct me now as I have several more patches I'll be trying to submit this week: https://code.launchpad.net/~ajorgens/cloud-init/python26/+merge/296575
[16:09] <smoser> ajorg, that looks fine. i'm really sorry about regressing 2.6 function
[16:09] <ajorg> Thanks.
[16:09] <ajorg> By way of introduction, I'm the cloud-init maintainer at AWS.
[16:09] <ajorg> (for the Amazon Linux AMI)
[16:10] <ajorg> We have a feature or two, several bugfixes, and a bunch of backward compatibility stuff for our 0.5 fork from before Yum / RPM were supported.
[16:11] <ajorg> I'd like to upstream whatever parts are palatable.
[16:11] <smoser> we need to get some c-i in place that can test on a 2.6.  the thing that makes it hard is that there is actally not even a python2.6 *available* in a supported ubuntu release (12.04 shipped 2.7)
[16:11] <ajorg> Anything I can do to get that in place?
[16:12] <ajorg> CentOS 6 testing would be prudent, and would cover 2.6
[16:12] <smoser> harlowja_at_home, has mentioned some options with his remote_tox
[16:12] <ajorg> cool
[16:12] <smoser> but yeah, we need to get this stuff in place.
[16:12] <harlowja_at_home> https://github.com/harlowja/remote_tox ifu care
[16:13] <smoser> dict comprehension is just so nice
[16:13] <smoser> i think thats the right word
[16:13] <ajorg> I know!
[16:13] <smoser> {a:b for a, b in d.items()}
[16:13] <harlowja_at_home> dict((a,b) for a, b in d.items()) ?
[16:13] <harlowja_at_home> just use the word 'dict' lol
[16:13] <smoser> harlowja_at_home, deal.
[16:14] <ajorg> Amazon Linux AMI has been on 2.7 for a few releases, so we won't be a fruitful source of 2.6 patches going forward.
[16:15] <ajorg> hmm, I get to learn how to do author attribution in bzr for some of these
[16:16] <smoser> ?
[16:16] <smoser> author attribution ?
[16:16] <ajorg> assuming it's possible, submitting a patch in someone else's name (other authors @amazon.com)
[16:17] <ajorg> I know how to do it in git.
[16:25] <smoser> ah. well you can commit with '--author='
[16:25] <smoser> that sprobably the thing you want.
[16:25] <smoser> then you become 'committer' and author is author
[16:28] <ajorg> perfect, very much like git
[16:28] <ajorg> thank you
[17:06] <smoser> larsks, fyi, i just uploaded a 0.29 tarball with your growpart fix https://launchpad.net/cloud-utils/trunk/0.29
[17:10] <larsks> smoser: thanks for the heads up!
[17:49] <harlowja> ok backs
[19:08] <larsks> This is a dumb question...under ubuntu, "python3 setup.py install ..." wants to put cloud-init into site-packages, but that dir doesn't exist.  What's the right way to install it?
[19:11] <larsks> Ah, --prefix=/usr/local seems to be the thing.
[19:12] <smoser> yeah, need some --prefix.
[19:12] <smoser> ./packages/bddeb though would probably be preferable in most cases
[19:12] <larsks> This is just for testing, not packaging...I was just confused by the "site-packages" does not exist error.
[19:13] <larsks> Apparently I haven't run setup.py on an ubuntu system before.


[01:02] <derekv> dood
[01:41] <Blazeix> rick_h_: a friend just posted this screenshot of his watch/build-system integration :) http://mrozekma.com/pebble-build-notification.jpg
[01:42] <Blazeix> implemented via redis subscribe
[01:59] <snap-l> Oh, that's nice.
[03:22] <derekv> is there a pyramid equivlent of flask-admin
[12:04] <tony-smlr> SMLR is Live!!  Video  http://www.youtube.com/user/tbemus?v=bADUZVqcf9M , Audio - http://live.smlr.us:8000/streaming
[13:07] <rick_h_> Blazeix: lol, awesome
[13:07] <rick_h_> wonder how he hooked it up, looks like it's not the usual 'send a text' setup
[13:09] <rick_h_> derekv: there's some stuff like formalchemy that supposedly will do that stuff. Honestly, cli on the db ftw, or scripts. Test helpers like makeUser and such are darn handy sometimes
[13:50] <rick_h_droid> party
[15:07] <snap-l> Good morning
[15:09] <rick_h_droid> morn
[15:18] <snap-l> "Thank you for your order from EliteKeyboards!
[15:18] <snap-l> This e-mail confirms that your order has been received and is
[15:18] <snap-l> now being processed."
 BLARGHALGHAGHLGHAGLAGHAGLAGHAGAGLAGHAGLA"
[15:21] <snap-l> And no doubt UPS will take a while to even get my order into their system
[15:21] <snap-l> patience... patience....
[15:22] <snap-l> https://www.youtube.com/watch?v=3z1WW70R88w
[16:50] <rick_h_> snap-l: it'll be ok
[17:06] <jrwren> why does python drive me mad?
[17:07] <rick_h_> jrwren: because it's not .net?
[17:19] <jrwren> no, becuase i'm shitty.
[17:19] <jrwren> not so much .net as F#.
[17:19] <jrwren> i just wish python was f# :)
[17:20] <rick_h_> yea, guess it's not going to be that
[17:20] <Blazeix> jrwren: have you seen http://dev-tricks.net/pipe-infix-syntax-for-python
[17:34] <jrwren> yes, I use it :)
[17:34] <jrwren> hell, i sent 'em a pull request for F# window function
[17:34] <Blazeix> haha, nice
[17:34] <jrwren> i LOVE that pipe library
[17:40] <jrwren> in this case, i was complaining that python wasn't reading my mind :)
[22:42] <rick_h_> *grumble, wives not able to hold onto documentation when you need it...*


[17:39] <Kaleo> rsalveti: hey
[17:39] <rsalveti> Kaleo: hey, what's up?
[17:39] <Kaleo> rsalveti: I upgraded my panda (dist-upgrade)
[17:40] <Kaleo> rsalveti: is there anything I need to do to make Ubuntu TV run faster? :)
[17:48] <rsalveti> Kaleo: are you using the linaro overlay ppa? (with oneiric)
[17:48] <rsalveti> faster than what I got running at my panda? guess you could have that by improving the driver or your own code :-)
[18:04] <Kaleo> rsalveti: yep I am (double checkingÃ)
[18:04] <Kaleo> rsalveti: so no secret local magic heh :)
[18:05] <rsalveti> Kaleo: not atm
[18:08] <robclark> fwiw, avoid metacity compositing or other window managers that are doing compositing..
[18:08] <Kaleo> rsalveti: yep
[18:08] <Kaleo> rsalveti: good point
[18:09] <robclark> but the normal ubuntu-tv setup should be fine for 1080p assuming all the hw decode/gpu, and eglimage supporting qtmobility is in place
[18:09] <Kaleo> robclark: good point :)
[18:09] <Kaleo> robclark: well, it's "fine"
[18:09] <Kaleo> robclark: just the rendering is not fast enough in my eyues
[18:09] <Kaleo> eyes*
[18:10] <robclark> hmm, it should be ok for 30fps or so at least..  although w/ unpatched qtmobility it will look like a slideshow..
[18:11] <robclark> I'm not sure if there is any debug option to enable fps display like you have in xbmc (if not, that would be a useful thing for development)
[18:11] <Kaleo> robclark: QML_SHOW_FRAMERATE=1
[18:11] <robclark> ahh, that is useful
[18:12] <Kaleo> robclark: in the worst moment I get frame painting taking up to 95ms
[18:12] <Kaleo> robclark: not quite 30fps :)
[18:12] <robclark> ugg, that doesn't seem right
[18:12] <Kaleo> robclark: not what you get?
[18:12] <robclark> I guess I would have noticed if it was only 10fps ;-)
[18:12] <robclark> I don't suppose it is happening every ~10sec?
[18:13] <robclark> (known issue caused by DVI support.. which somehow I don't see on ubuntu 11.10 kernel)
[18:13] <Kaleo> robclark: hmmm, no, it's happening when I scroll up and down in the dash' categories
[18:14] <Kaleo> robclark: it's using HDMI
[18:14] <robclark> oh, hmm, ok..   I had been paying more attention to video playback and less to the GUI..
[18:14] <Kaleo> robclark: it's 1920x1080
[18:14] <Kaleo> :)
[18:14] <robclark> fwiw, that issue was effecting HDMI.. it was caused by a delay when polling DVI for connection (which happens every ~10s)
[18:15] <robclark> but that would be some delay that you hit every ~10s or so
[18:16] <robclark> fwiw, I think a proper database is needed for handling large libraries of videos..  I had noticed that if I have a lot of videos in my lib that slows down the UI..
[18:16] <robclark> (I guess it ends up opening the .nfo files for each clip?)
[18:16]  * robclark has ~500gb of clips, which xbmc handles ok, but brings ubuntu-tv to it's knees
[18:17] <robclark> (but I attribute that to the early prototype stage of ubuntu-tv)
[18:32] <Kaleo> robclark: oh yeah, the look up of videos is absolutely not production ready
[18:32] <Kaleo> robclark: it's a quick hack
[18:32] <Kaleo> robclark: and a store (db) is dearly needed
[18:32] <robclark> yeah.. at least things like seek/pause/play work well w/ native gst decoder..
[18:33] <robclark> but I really look fwd to the point where I can start using ubuntu-tv for real instead of xbmc
[18:33] <Kaleo> robclark: :)
[18:33] <Kaleo> robclark: if you happen to have figures from QML_SHOW_FRAMERATE, let me know
[18:34] <robclark> ok.. will probably be tonight, I have ubuntu-tv setup on my htpc panda in my livingroom
[19:20] <tgm4883> Has the UbuntuTV stuff made it back to Unity that is in 12.04 yet?
[19:25] <tgm4883> Kaleo, is that (a db) in the roadmap? Or is it something that would need to be done in the scope side?
[19:26] <Kaleo> tgm4883: no it has not made it back yet
[19:26] <Kaleo> tgm4883: it won't be included in 12.04
[19:26] <Kaleo> tgm4883: too late for that
[19:26] <tgm4883> hmm
[19:26] <Kaleo> tgm4883: but there is an idea of having a PPA with a more polished version of it though
[19:26] <tgm4883> Kaleo, I'm setting up a 11.10 VM that I can play with
[19:27] <tgm4883> I can only get so far using only the video lens
[19:27] <Kaleo> tgm4883: hmmm, better if you have a VM with hw accelerated OpenGL enabled
[19:27] <tgm4883> Speaking of, the DVR functionality, would that be considered a lens as well?
[19:30] <tgm4883> Kaleo, basically, I'm trying to figure out the best place to put mythtv recordings for this. Right now I've got it going to the videos lens, but that doesn't work out so well since the videos lens is trying to get data from .nfo files
[19:31] <tgm4883> I'm setting up a test environment so I can see how things in the recordings directory are handled, that might answer my question a bit better
[19:48] <Kaleo> tgm4883: it would not be considered a lens since it does not use at all the lens infrastructure
[19:48] <Kaleo> tgm4883: actually I thought you meant EPG
[19:48] <Kaleo> tgm4883: for the recordings themselves
[19:49] <Kaleo> tgm4883: they are supposed to appear in the last category of the video lens
[19:49] <Kaleo> tgm4883: design wise, though of course, it's not implemtned :)
[19:49] <Kaleo> tgm4883: I gotta dash
[19:49] <Kaleo> tgm4883: have a nice evening!
[19:52] <tgm4883> Kaleo, thanks for the info
[19:57] <mhall119> tgm4883: ideally you would have a mythtv scope that feeds data about available videos to the video lens
[19:57] <tgm4883> mhall119, yea that is what I have right now :)
[19:58] <tgm4883> unfortunately all it does is feed the URI, there doesn't seem to be the ability to feed it much more than that, title and comment
[20:00] <mhall119> uri, name and description
[20:00] <mhall119> what else do you need?
[20:00] <mhall119> are you talking the extended description and whatnot they have in the demo?
[20:01] <mhall119> that's not currently supported by the Lens infrastructure
[20:01] <mhall119> it may have to be a separate app
[20:07] <tgm4883> mhall119, description, season, episode
[20:07] <tgm4883> things you would generally want in a DVR ;)
[20:08] <mhall119> tgm4883: hmm, that would make sense for episodic shows, but not movies
[20:08] <tgm4883> mhall119, which is what mythtv is used for


[02:24] <cheater> hi
[02:25] <cheater> can someone tell me how to get aufs support (for docker) on ubuntu 14.04 64-bit?
[02:25] <cheater> on a vanilla system docker uses device mapper and its support is buggy (it cannot be worked around, i need to start using aufs)
[02:25] <cheater> (but apparently aufs is better anyways)
[02:26] <cheater> i would appreciate any sort of help with this
[12:40] <pkern> cheater: Depending on your environment you need to install linux-image-extra-* for aufs.
[12:48] <apw> otherwise it should just be there to use by default, not sure i know any more about the docker configuration to help with that though
[15:28] <cheater> pkern: as i said, i managed to do that already. i just wonder if btrfs has any advantages over aufs.
[15:30] <cheater> pkern: oh sorry i said that in another channel :)
[15:31] <cheater> pkern: thanks for your help :) i guess i managed to figure this stuff out before you answered and then forgot i came here to ask, and after that i mixed up the channel windows!
[15:35] <pkern> cheater: http://www.projectatomic.io/docs/filesystems/
[15:36] <pkern> cheater: Especially the last section.
[15:38] <cheater> hey that's an interesting link, thanks pkern


[17:16] <gastly> hi guys, I need some help with contributing to the kubuntu docs, anyone around who can help?
[17:44] <starcraftman> gastly: we talking bout system or wiki?
[17:44] <gastly> the system ones
[17:44] <gastly> for lucid
[17:45] <starcraftman> I don't work for kubuntu docs, but can offer info. jjesse works for em be sure to ping him later when he pops on. Whats trouble?
[17:46] <starcraftman> gastly: ^
[17:46] <gastly> starcraftman, well, actually, it's about the graphics category that's in the ToDo list.
[17:46] <starcraftman> oh specific questions, guess I can't help on that. If it was more of how to contribute that I can answer.
[17:47] <gastly> ahh, well, I guess I'll send a mail to the list then. Thanks for your help :)
[17:47] <starcraftman> gastly: that is always an option.
[17:48] <starcraftman> If ya wait long enough I'm usre jesse would pop back in.
[17:49] <gastly> cool, but it's kinda late here hehe, so can't stay for long =)
[17:51] <starcraftman> gastly: rgr, then send a mail to list, I'll tell jesse when he pops back.
[17:51] <gastly> starcraftman, cool thanks
[17:54] <starcraftman> gastly: np, and thanks for helping with docs.
[17:55] <gastly> it's always a pleasure to help out the community :)
[21:58] <stlsaint> DarkwingDuck: ping


[13:36] <cjwatson> wgrant: Looks like you need some more preloading on SPRB
[13:37] <wgrant> cjwatson: Already pushed and awaiting more failures :)
[13:39] <cjwatson> Ah :)
[13:40] <wgrant> Though, shockingly, it seems like that's the extent of them.
[14:29] <cjwatson> wgrant: And now it's my turn, I see
[14:29] <cjwatson> Also WTF, I ran those tests, I'm nearly sure
[14:30] <cjwatson> I mean, I ran -t mail
[14:30] <cjwatson> oh, I had a layer setup failure I didn't notice :(
[14:30] <wgrant> Heh
[14:57] <wgrant> Oh, that testfix wasn't nearly as bad as I expected.
[15:00] <cjwatson> Amazing how much test failure verbiage can be caused by a small amount.
[16:58] <cjwatson> Hm, snap-listings is harder than I thought.  Branch.recipes etc. can be fairly naïve, but they get away with that because recipes don't support private branches.  I need something a bit more like Branch.getMergeProposals.
[17:01] <cjwatson> Well, maybe Branch.snaps is OK, but at any rate Person.snaps (or equivalent) has to limit to snap sources that you can see.
[17:02] <cjwatson> At least we don't have to deal with intersections between privacy of multiple branches.
[17:02] <cjwatson> BranchCollection.getMergeProposals /o\