[00:28] <kaushal> hi micahg
[00:28] <kaushal> I am hit with this bug https://bugs.launchpad.net/ubuntu/+source/kickseed/+bug/548617
[00:29] <kaushal> Any fix is available for this bug ?
[00:35] <micahg> kaushal: according to this it was fixed before lucid was released
[00:35] <kaushal> ok
[00:35] <kaushal> micahg: not sure although
[00:36] <kaushal> I am using PXE to install lucid 10.04.3
[00:36] <kaushal> micahg: as per comment #10 it says use new debian installer
[00:36] <kaushal> does that fix the issue ?
[00:37] <micahg> kaushal: I have no idea
[00:37] <EvilResistance> micahg:  you wouldnt happen to know where the debian support home is would you?
[00:37] <EvilResistance> for IRC
[00:37] <micahg> EvilResistance: #debian-support on OFTC?
[00:37] <EvilResistance> thanks
[00:37] <kaushal> micahg: where do i seek further help ?
[00:38] <micahg> kaushal: #ubuntu-installer maybe (idk if they do support) or possibly #ubuntu
[00:38] <kaushal> ok
[00:49] <kaushal> micahg: is there a search feature for ubuntu bugs ?
[00:49] <kaushal> I mean similar to google
[06:39] <nitinab> Hello room, i am new at gui programming and was wondering what would be the way to go about learning it and writing a simple application that i have in my head. Option right now are Glade/Python or Qt4/python
[07:21] <pmjdebruijn> nitinab: if Ubuntu is your main target I'd highly suggest Glade/Python
[07:21] <pmjdebruijn> since most Ubuntu apps are Gtk
[07:21] <RAOF> nitinab: Well, GTKBuilder/Python.  Qt/python is also perfectly acceptable.  I've only ever really done GTK development, though.
[07:23] <broder> i've always found gtk's layout model to be unfathomable, but could trivially make qt lay things out the way i wanted
[07:23] <nitinab> what i am doing right now is glade/python, but i was wondering if qt/python would be easier to learn, if all i need is to have a working app to show my concept in the next 10 hours
[07:24] <RAOF> I've not tried qt/python.  I've found it trivial to whip up a gtk/python app, though.
[07:24] <micahg> well, there's QT creator, but I haven't played with it
[07:25] <RAOF> You could also go all Qt Quick, if javascript's your thing.
[07:26] <nitinab> ok qt quick is something i didn't know about, but i am trying to stick to python for now
[07:30] <pmjdebruijn> these days I'd probably go with Vala/GTK
[07:31] <broder> i don't think i'd recommend vala
[07:31] <broder> it feels underevolved to me still
[07:31] <broder> too many rough edges and not enough docs
[07:32] <nitinab> but its supposed to be faster, leaner
[07:32] <RAOF> It's less painful than writing gobject in C, certainly.
[07:32] <pmjdebruijn> and it's object model fits exactly onto GObject
[07:33] <broder> i would probably choose vala over c, but i don't think i'd choose it over python for quick prototyping
[07:33] <RAOF> Because it's an automatic C/gobject generator :)
[07:33] <pmjdebruijn> I used to love Mono/GTK#, but then your stuck with Mono
[07:34] <broder> in fairness, a lot of the sourness of my experience is because the library i'm working with has terrible introspection data
[07:35] <nitinab> so i can prototype in python right now, and if it ever grows big enough that speed is an issue, rewrite the code into vala?
[07:35] <pmjdebruijn> you can
[07:35] <pmjdebruijn> but it's probably not the best way to go
[07:36] <broder> i think it's a fine way to go
[07:36] <broder> size of a codebase isn't indicative of performance problems
[07:36] <broder> and there tend to only be a handful of things that are performance sensitive anyway
[07:37] <RAOF> Which is why python C extensions exist :)
[07:37] <broder> precisely!
[07:37] <broder> or even better, vala libraries with good introspection data + pygobject
[07:38] <broder> if you have 10 hours to build a functioning demo, i don't think you want to be bothering with C or a glorified annotated C preprocessor
[09:06] <_ruben> brainfart, what is the usual version numbering 'scheme' when packaging a release candidate version? 0.14.0~rc3-1 for instance, or was it something else?
[09:06] <pmjdebruijn> sounds cool
[09:06] <pmjdebruijn> _ruben: I guess it should be 0.14.0~rc3-0
[09:06] <pmjdebruijn> since -1 is used upstream by debian?
[09:06] <_ruben> 0.14.0-1~rc3 just doesn't look right to me, which would be the closest alternative
[09:07] <pmjdebruijn> nooo
[09:07] <pmjdebruijn> _ruben: that's basically saying the pacakaging is in rc3 version, not the software itself
[09:07] <_ruben> ubuntu/debian are still at 0.12.1 ;) (pmacct)
[09:07] <_ruben> ah right
[09:07] <pmjdebruijn> I know
[09:08] <pmjdebruijn> but if there is going to be an official upstream package it will get the package version -1
[09:08] <pmjdebruijn> so for personal use you'd want to go _under_ that
[09:08] <pmjdebruijn> so 0.14.0~rc3-0
[09:08] <_ruben> ah ok
[09:08] <pmjdebruijn> I usually "tag" my packages for personal use too
[09:08] <pmjdebruijn> so 0.14.0~rc3-0pmjdebruijn1~lucid for example
[09:09] <pmjdebruijn> for my PPAs
[09:09] <_ruben> that's an area i still need to create some consistency in, i sometimes do/don't use such a custom suffix
[09:09] <pmjdebruijn> I'm not sure what the exact rules are for submittence to the MOTU's are
[09:09] <_ruben> the 0 and 1 should be interpretted how exactly btw? of the pmjdebruijn part that is
[09:10] <pmjdebruijn> huh?
[09:10] <_ruben> never figured that one out ..
[09:10] <pmjdebruijn> everything after the - is the package version
[09:10] <_ruben> yeah, but why prefix with 0 and use 1 as suffix
[09:10] <pmjdebruijn> -1 is used upstream by debian
[09:10] <pmjdebruijn> usually you'd want to get your custom pacakges replaced by debian upstraem versions once they are available
[09:10] <pmjdebruijn> Debain starts with -1
[09:10] <_ruben> oh right, doh, that's the same 0 as discussed efore
[09:11] <_ruben> i need to wake up it seems :p
[09:11] <pmjdebruijn> it's not that hard :p
[09:11] <pmjdebruijn> it's just {SOFTWARE_VERSION}-{PACKAGING_VERSION}
[09:12] <_ruben> yeah, it's the numbering within the PACKAGING_VERSION that confused me for a bit, but it's clear now :)
[09:12] <pmjdebruijn> it's just a number
[09:13] <pmjdebruijn> in my example is 0 (to keep under future Debian packages), my tag 'pmjdebruijn', and my own version '1', suffixed by a dist '~lucid'
[09:13] <_ruben> yeah
[09:13] <pmjdebruijn> but that's my "private" scheme for my PPA
[09:13] <pmjdebruijn> not for upstream submittance
[09:13] <_ruben> understood
[09:13] <pmjdebruijn> the nice thing is that customized packages can easily be identified
[09:13] <pmjdebruijn> dpkg -l | grep pmjdebruijn
[09:13] <pmjdebruijn> :D
[09:14] <pmjdebruijn> ubuntu  uses a similar scheme when they modified debian packages
[09:14] <_ruben> interesting, hadn't thought of that one :)
[09:14] <pmjdebruijn> for example a ubuntu modified debian packages with version 0.14.0-1 becomes 0.14.0-1ubuntu1
[09:14] <pmjdebruijn> which is what I based my scheme on
[09:18] <_ruben> i really oughta do some ppa-like automation on my local build system .. like updating the ubuntu release name in changelog and build for that appropriate release, for both i386 and amd64 .. should be fairly trivial to implement i guess
[09:18]  * pmjdebruijn just uses PPAs
[09:19] <pmjdebruijn> allowed others to benefit as well
[09:19]  * EvilResistance has his own ubuntu repository system set up
[09:19] <EvilResistance> but its a private system :p
[09:20] <_ruben> using ppas has crossed my mind as well, never really looked at how easy it would be to sync the ppas with my local repo .. then again, i plan to change from using debmirror to plain rsync someday anyway .. and possibly use debmirror or whatever to sync any ppas i might have by then
[09:21] <pmjdebruijn> _ruben: sync? apt-mirror?
[09:22] <_ruben> there's several syncing methods, with each their own pros and cons .. should re-evaluate some day, as current setup has been around for a while now
[09:22] <_ruben> since feisty or so
[09:23] <_ruben> anyway .. thanks for the versioning pointers, afk for a bit
[09:23] <pmjdebruijn> npo
[09:36] <nitinab> how can i change the editor in ubuntu quickly system, my gedit isn't working
[09:41] <pmjdebruijn> "change the editor"
[09:41] <pmjdebruijn> install another one and use it?
[09:42] <pmjdebruijn> oh wait
[09:42] <pmjdebruijn> the application 'quickly'
[09:42] <pmjdebruijn> doh
[09:42]  * pmjdebruijn is silly
[14:46] <Laney> hm, can syncpackage -s ... -b xxx indicate that the sync was sponsored in the message?
[14:51] <tumbleweed> what message?
[14:52] <tumbleweed> oh, you said -b
[14:52] <Laney> it's ok i filed it
[17:06] <jtaylor> was the localhost binding issue on the builders fixed?
[17:15] <tumbleweed> sounds like you are the person most likely to know ;P
[17:16] <jtaylor> hm I'll just try a rebuild
[18:04] <jtaylor> nope :/
[18:04] <jtaylor> but it does not affect the armhf and armel builders
[20:01] <tumbleweed> jtaylor: I guess you need to poke lamont