[00:00] <lzantal>  where can I get more info on motu-school?
[00:18] <Adri2000> zul: ping
[01:02] <zul> Adri2000: yep
[01:21] <Adri2000> zul: what happened to the fail2ban sru?
[02:14] <zul> Adri2000: dont know Ill have a look tomorrow
[03:45] <eddyMul> I would like to put python-django through FreezeExceptionProcess
[03:46] <eddyMul> what's a good bug title?
[03:46] <eddyMul> s/title/summary/
[03:48] <eddyMul> would "intrepid should include python-django_1.0" work?
[03:49] <RAOF> "FFe for 1.0" sounds about right.
[03:50] <eddyMul> RAOF: I'll use that. Thanks.
[04:11] <superm1> kirkland, ping
[04:12] <kirkland> superm1: howdy!  how was the 10K?
[04:12] <superm1> hi kirkland.  well unfortunately i didnt get to run it
[04:12] <kirkland> superm1: bummer :-/
[04:12] <superm1> i broke my ankle 3 weeks before
[04:12] <kirkland> superm1: jesus H
[04:12] <kirkland> superm1: that sucks
[04:12] <superm1> kirkland, yeah during one of my training runs i slipped on a curb
[04:12] <superm1> twisted my ankle, there was a loud *pop* and next thing i know i'm in ER getting some xrays
[04:13] <superm1> one chip and one break :(
[04:15] <superm1> kirkland, being that you've touched sysvinit a bunch, I was hoping you might be able to help explain/figure out what's going on with this crash report: http://pastebin.com/f2cc4c86e
[04:16] <kirkland> superm1: that sucks so much, so sorry to hear :-/
[04:16]  * kirkland looks
[04:16] <superm1> kirkland, yeah i've come to terms with it, but i was pretty heartbroken.  there's tons more races coming in oct, so i should hopefully be out of the cast in 2 more weeks and able to start training again
[04:16] <kirkland> superm1: yeah, i hear yah....
[04:17] <kirkland> superm1: if it makes you feel any better....
[04:17] <kirkland> superm1: i trained for the 2007 Marine Corps Marathon in Washington DC last year, over the course of 6 months
[04:17] <kirkland> superm1: 4 weeks before the race, I was in the top condition of my life, ready to run the race of my life
[04:18] <kirkland> superm1: i did a 20 mile run on a Saturday morning
[04:18] <kirkland> superm1: and on Sunday, I should have stayed home and watched football
[04:18] <kirkland> superm1: instead, I went rock climbing with friends
[04:18] <superm1> kirkland, oh man, i see where this is headed
[04:18] <kirkland> superm1: if that wasn't enough, I had to go jumping off of a crazy rope swing
[04:18] <kirkland> superm1: and if that still wasn't enough, I had to climbing higher and higher into the tree to get the swing of a lifetime
[04:19] <kirkland> superm1: well, i swung out so far, i landed in a sandbar
[04:19] <kirkland> superm1: landed in about 3 feet of water
[04:19] <kirkland> superm1: sprained my ankle and knee
[04:19] <kirkland> superm1: heartbroken, of course
[04:19] <kirkland> superm1: no break, thankfully
[04:19] <superm1> kirkland, ouch, how much time between then and when the race was supposed to be?
[04:20] <kirkland> superm1: exactly 4 weeks to the day
[04:20] <kirkland> superm1: i couldn't put weight on it for the first week
[04:20] <kirkland> superm1: the next 2 weeks I hobbled around
[04:20] <kirkland> superm1: week 3, I ran the IBM 10K in a lot of pain
[04:20] <superm1> yeah i'm just starting to put weight on mine at the 3.5 week mark but still hobbling
[04:20] <kirkland> superm1: week 4, I "ran" the marathon, with my entire shoe taped
[04:20] <kirkland> superm1: i was an hour slower than my goal time
[04:21] <kirkland> superm1: and ran in a lot of pain, but I finished :-)
[04:21] <superm1> kirkland, but you still finished though on a sprained ankle/knee
[04:21] <superm1> i hope no permanent damage?
[04:21]  * kirkland really goes look at the pastebin now
[04:21] <kirkland> superm1: no, i don't think so
[04:21] <kirkland> superm1: i did a half-marathon in April and had a lot of fun, no pain
[04:21] <kirkland> superm1: i'm just starting to think about the Austin Marathon which is in February now
[04:22] <kirkland> superm1: i haven't decided if i'm doing it or not, yet
[04:22] <superm1> kirkland, that's good.  i'll admit i half though of just dosing up on vikaden and trying to run through it, but realized that was a bad idea since i'm just starting to be weight bearing :)
[04:22] <kirkland> superm1: yeah, just save it until you're 100%
[04:22] <kirkland> superm1: you'll enjoy it so much more!
[04:22] <superm1> well if you are thinking for feb, let me know what training group you go with.  depending on how my healing it looking, maybe i can try to shoot for a half marathon at that time with you
[04:23] <kirkland> superm1: the Marine Corps marathon was different, because I had already bought plane tickets, hotel reservations, my mom and dad were going, i was running with a friend, etc. etc. etc.
[04:23] <kirkland> lots of peer pressure
[04:23] <superm1> oh wow
[04:23] <kirkland> superm1: that sounds good ;-)
[04:23] <kirkland> superm1: but you're right, there are a dozen 10K's in Austin
[04:23] <kirkland> maybe more, actually
[04:24] <superm1> well that and 5k's, so a nice healthy mix that i'll have a variety to look forward to
[04:24] <kirkland> superm1: so are you thinking the problem is with #
[04:24] <kirkland>  update-rc.d: symlink: No such file or directory
[04:24] <kirkland> #
[04:24] <kirkland>  dpkg: error processing mythtv-backend (--configure):
[04:24] <kirkland> #
[04:24] <kirkland>   subprocess post-installation script returned error exit status 2
[04:25] <kirkland> superm1: or somewhere further up?
[04:25] <superm1> kirkland, that's what i'm thinking is causing the crash
[04:25] <superm1> but i don't recall ever changing any of the update-rc.d code in the init scripts for intrepid
[04:25] <kirkland> superm1: let me pull the source to mythtv-backend
[04:27] <superm1> kirkland, i believe all that the postinst ends up doing (after debhelper) is         update-rc.d mythtv-backend defaults 24 16 >/dev/null
[04:27] <superm1> kirkland, which is identical to the behavior that dh_installinit added in hardy too
[04:29] <kirkland> dh_installinit -a -u'defaults 24 16'
[04:30] <superm1> yeah in debian/rules, i suppose that's what propogates the update-rc.d into the postinst.
[04:30] <superm1> should that be different then?
[04:31] <kirkland> superm1: looking at one that I did recently, for the update-motd package (from scratch), I used:
[04:31] <kirkland> dh_installinit -- start 81 2 3 4 5 . stop 19 1 .
[04:31] <superm1> kirkland, so what does that actually translate into meaning?
[04:31] <kirkland> superm1: 81 = start priority
[04:32] <superm1> ah and then 1 2 3 4 5 runlevels
[04:32] <superm1> 19 is stop priority, only stop in 1 runlevel
[04:32] <kirkland> right
[04:32] <kirkland> so I think you want the start priority at 24
[04:32] <kirkland> superm1: and the stop at 100 - 24
[04:32] <kirkland> superm1: 76 so says my math :-)
[04:33] <kirkland> superm1: you want it to start in 2 3 4 5 run levels
[04:33] <superm1> well how to decide what runlevels?
[04:33] <kirkland> superm1: and only stop in 1
[04:33] <kirkland> superm1: okay, so here's where my lack of upstart knowledge starts to show
[04:33] <superm1> isn't this doubled up though, the same things go in the header of the init script itself (which apparently is wrong too)?
[04:33] <kirkland> superm1: and perhaps some of my long-time RH background....
[04:34] <kirkland> superm1: the stuff in the header of the init script is comments only, as far as I understand
[04:34] <kirkland> superm1: and yes, those should be cleaned up as part of this patch
[04:34] <superm1> kirkland, oh, i wonder why lintian actually cares about that stuff then
[04:34] <superm1> kirkland, should there be any worry for upgraders with this though?
[04:34] <kirkland> superm1: i think it's cleanliness and good manners
[04:35] <kirkland> superm1: there could be more to it than that...  i'll ask some people smarter than I tomorrow :-)
[04:35] <kirkland> superm1: good question... i'd hope the debhelper would take care of that cleanly for you
[04:35] <superm1> kirkland, woah actually changing the top of the init script did change behavior (changing Default Start to 2 3 4 5) allows update-rc.d to not bail out
[04:35] <kirkland> superm1: but I'm not sure
[04:36] <kirkland> superm1: interesting....  i do agree that those need to be kept in sync and accurate
[04:36] <kirkland> superm1: but I don't know who/what reads/cares about that commented data
[04:36] <superm1> kirkland, well perhaps i'll have to look at another service package like mysql and just try to emulate the way that are doing it.  it's odd that it bailed out suddenly in intrepid
[04:36] <kirkland> superm1: good call, mysql is well packaged
[04:37] <superm1> kirkland, yeah i definitely never agree with reading commented data, but empirical results seem to indicate it matters in this case
[04:37] <kirkland> superm1: gotcha
[04:37] <superm1> kirkland, okay well thanks for the push in the right direction here :)
[04:37] <kirkland> superm1: back to another question of yours.... you do understand the various runlevels, right?
[04:37] <kirkland> superm1: no prob, not sure how much I helped, other than moral support ;-)
[04:38] <superm1> kirkland, i've got a basic understanding of them, but as upstart was introduced in the mix not as much
[04:38] <kirkland> superm1: agreed, Upstart is the monkey-wrench
[04:38] <kirkland> superm1: something like this might help just a bit http://www.debianadmin.com/debian-and-ubuntu-linux-run-levels.html
[04:38] <kirkland> superm1: or even wikipedia
[04:39] <superm1> kirkland, ah thanks.  i'll see if things appear to look more clear after looking over that
[04:39] <kirkland> superm1: sure
[04:40] <kirkland> superm1: in brief, setting it to run in 2 3 4 5 basically says "run myth-backend once the system is in any multi-user runlevel"
[04:42] <kirkland> superm1: which does not include runlevel 1 (single user mode), which is primarily used for system rescue
[04:42] <superm1> kirkland, so why are 3-5 even around then?  with upstart being in the mix, is graphical login really defined for level 5?
[04:43] <kirkland> superm1: in the RH world, the only ones that make sense are 1 (single user), 3 (command line only, with networking), and 5 (full X stack, with networking)
[04:44] <kirkland> superm1: and 2 and 4 are reserved (not used)
[04:44] <superm1> kirkland, so perhaps in the ubuntu world 3-5 are really just around for compatibility reasons then?
[04:44] <kirkland> superm1: Upstart isn't quite read to supplant rc*.d yet
[04:45] <kirkland> superm1: and thus the various runlevels are still around
[04:45] <kirkland> superm1: exactly
[04:45] <superm1> kirkland, ah that seems to make more sense then
[04:46] <kirkland> superm1: from the Upstart wikipedia article, "Easy transition and perfect backwards compatibility with sysvinit were explicit design goals"
[04:48] <superm1> kirkland, so looking at mysql-server's dh_installinit line, it look like dh_installinit -a --name=mysql -- defaults 19 21 is used
[04:48] <superm1> that would mean 19 is the default starting priority and 21 is the default stopping priority
[04:48] <superm1> with the runlevels determined by dh_installinit, correct?
[04:49] <kirkland> superm1: yeah, look on your mythbackend: /etc/rc0.d/K21mysql
[04:49] <kirkland> superm1: and /etc/rc5.d/S19mysql
[04:49] <kirkland> superm1: remember, rc0 is the shutdown runlevel
[04:50] <superm1> kirkland, right, this seems sensible and easy enough to fix then
[04:50] <kirkland> superm1: i think "S" stands for "start", and "K" for kill
[04:50] <kirkland> superm1: also, please consider whether or not a shutdown action is necessary for mythbackend
[04:50] <kirkland> superm1: there's been some effort to reduce the number of unnecessary shutdown scripts
[04:50] <superm1> you mean optionally just leaving the backend running?
[04:51] <kirkland> superm1: as it slows down shutdown/reboot
[04:51] <kirkland> superm1: well, just consider if its necessary
[04:51] <superm1> kirkland, dont most processes not like that kind of behavior and not having an option to clean up?
[04:51] <kirkland> superm1: there exist some daemons that don't really actually need to be shutdown by it's init script (killing the process is clean enough)
[04:51] <superm1> kirkland, well i suppose i've never tried, but that should be something explored later i believe
[04:51] <kirkland> superm1: most, right.  but not all.
[04:52] <kirkland> superm1: fair enough, just thought i'd mention it
[04:52] <superm1> kirkland, so if no shutdown scripts were included, how is that achieved?
[04:52] <superm1> not installing with defaults and two priorties, but instead just start and one priority?
[04:53] <kirkland> superm1: i think that's right, but I'd have to test it out ;-)
[04:53] <kirkland> superm1: we can look at that later, if you wish
[04:53] <superm1> kirkland, okay for now then defaults will suffice, and i'll try to remember to look at this later indeed :)
[04:53] <kirkland> superm1: just something I thought I'd mention in passing
[04:54] <kirkland> superm1: i have a feeling that mythbackend will want an explicit shutdown
[04:54] <superm1> yeah i seem to think it needs it because it has to issue commands to a master backend to say it's leaving the netwrok
[04:54] <kirkland> superm1: right, that's probably enough right there
[04:55] <kirkland> superm1: consider, for a moment, mythtv-status, though
[04:55] <kirkland> superm1: the thing that updates /etc/motd....
[04:55] <superm1> kirkland, yeah mythtv-status most definitely doesn't need it on shutdown at all
[04:55] <kirkland> superm1: there's no good reason that needs to run on shutdown
[04:55] <kirkland> superm1: right, so that's just your counterexample, in the interest of education ;-)
[04:56] <superm1> kirkland, well this type of exercise is indeed important and should be done on all types of daemons though if there is going to be an improvement
[04:56] <kirkland> superm1: you bet.
[04:56] <kirkland> superm1: were you willing to add the status action to the myth-backend init script?
[04:56] <kirkland> superm1: i'd really, really like to have that one on my backend ;-)
[04:57] <kirkland> superm1: i sent a patch at some point, you asked about backporting
[04:57] <superm1> kirkland, yeah i remember the issue was regarding older releases not supporting status
[04:57] <kirkland> superm1: i can work something up that would work for hardy pretty easily, but the code would be slightly different
[04:57] <superm1> kirkland, how about this for a happy medium;
[04:57] <superm1> kirkland, install different init scripts in debian/rules depending on which release it is getting built against?
[04:58] <superm1> so there would be a new style init script for newer releases that support status
[04:58] <superm1> and once the earlier releases that didn't support it hit EOL, the old style one got dropped
[04:58] <kirkland> superm1: hmm, if you're okay with the code duplication, i suppose that would solve the problem
[04:59] <kirkland> superm1: i'd think you'd want to avoid two copies of nearly identical init scripts
[04:59] <superm1> kirkland, well the other option is to append the function to init scripts on releases that support it
[05:00] <kirkland> superm1: right, so within the initscript, we could see if the status_of_proc() function is defined
[05:00] <kirkland> superm1: and if not, then we'll define it
[05:00] <kirkland> superm1: actually.....
[05:00] <kirkland> superm1: it can be done a little simpler than that
[05:00] <superm1> kirkland, more or less.  and once the earlier releases that don't support it are gone, drop that snippet
[05:00] <kirkland> superm1: let me dig through some patches i've done for dapper
[05:01] <kirkland> superm1: some people asked me for help getting something similar working for dapper
[05:01] <kirkland> superm1: and i put something together
[05:01] <kirkland> superm1: how about i send you a patch tomorrow for your review
[05:01] <superm1> kirkland, sure, if you want to drop me a patch sometime tonight, i'll throw it in the upload i'll do.
[05:01] <kirkland> superm1: with the explicit goal of having a single init script that works for Hardy & Intrepid
[05:01] <superm1> kirkland, or tomorrow should be fine, i suppose it is getting late
[05:01] <kirkland> superm1: yeah, i need to call it a night
[05:02] <superm1> kirkland, i'll put off the upload pending hearing back from you then
[05:02] <kirkland> superm1: i'll have a much easier time with this tomorrow, when i'm fresh, and have some coffee ;-)
[05:02] <kirkland> superm1: okay, i'll do it first thing, won't take very long at all
[05:02] <superm1> kirkland, okay just give superm1|away a diff then.   have a good evening :)
[05:02] <kirkland> superm1: take care of that ankle ;-)
[05:03] <superm1> thanks
[05:05] <nixternal> what's up MOTU land
[05:05] <nixternal> have a few minutes to bug ya while my smoke tests complete so I can go to bed
[05:06] <ajmitch> nixternal!
[05:06]  * nixternal needs to get list admin stuff on his worky lappy or on the server so he doesn't have to fire up another machine
[05:06] <nixternal> wasabi ajmitch
[05:06] <nixternal> my job is trying to kill me I think
[05:06]  * ajmitch is just amusing himself watching people 'debate' on IRC about stuff
[05:07] <nixternal> note to self: do not continuously press ctrl+o in mutt thinking it is ctrl+p instead
[05:07] <ajmitch> heh
[05:08] <nixternal> you can only open a folder so many times
[05:08] <ajmitch> nenolod: you should avoid feeding trolls, btw :)
[05:09] <nenolod> ajmitch: lol.
[05:09] <nenolod> ajmitch: but he is so amusing
[05:09] <ajmitch> sure...
[05:09] <nixternal> how long ago did this happen? I like watching and reading about trolls
[05:10] <nixternal> trolls == success
[05:10] <ajmitch> #chromium-linux
[05:10] <nixternal> ahh
[05:10] <ajmitch> ongoing discussion
[05:10] <nixternal> tell the troll to package RPMs all day, I bet they quit trolling
[05:11] <ajmitch> sounds like fun!
[05:11] <nixternal> hell no, I hate it!
[05:11]  * ajmitch wishes he got to package RPMs all day long
[05:11] <nixternal> you can have my job if they don't change to at least Ubuntu/Debian soon
[05:12] <ajmitch> heh
[05:12] <nixternal> I am trying to get them to work on a partnership with rPath now
[05:12] <nixternal> if they don't want to do that, then I will talk with Mark about a partnership
[05:13] <nixternal> they don't want to pay for rMirror, but rMirror and rBuilder cannot be beat in the appliance world
[05:13]  * ajmitch doesn't know who you work for or what you package
[05:13] <nixternal> I work for a company called Cleversafe (http://www.cleversafe.com)
[05:14] <nixternal> we do distributed storage appliances with a goal of eliminating Red Hat and Amazon in their clouds which are useless
[05:14] <ajmitch> interesting
[05:14] <nixternal> I am tired of looking at Python, Java, and RPMs
[05:14] <ajmitch> but python is fun
[05:14] <nixternal> I need another C++ job
[05:15]  * ajmitch mostly does PHP at work, so it can't be all bad for you
[05:15] <nixternal> perl is more efficient, no matter how much I hate writing in it
[05:15]  * RoAkSoAx does nothing at all :P xD
[05:15] <nixternal> right now udev is kicking my arse with a "fake arse hot-swap" in appliance regeneration
[05:16] <nenolod> amazon EC2 is way expensive
[05:16] <nixternal> I have the pulls working just fine...I even have the inserts working just fine and my killer Python script regenerating the appliance...but when I start up the machine, my udev rule gets called and creates a groovy kernel panic
[05:17] <nixternal> EC2 is inefficient imho, especially considering the storage options are sans
[05:17] <nenolod> nixternal: i am trying to bring rPath/conary-style inheritance to debian. but probably this will become a lenny+1 thing.
[05:18] <ajmitch> lenny+1 isn't far off
[05:18] <nixternal> with cleversafe we have what is called a dsnet....you have a minimum of 8 storage machines (slicestors) that break up your data into very small encrypted bits (the only proprietary part of our software btw) and stores them in various locations (vaults) on the dsnet
[05:19] <nenolod> ajmitch: i have it working in my own playground distro
[05:19] <nixternal> nenolod: which functionality? rollback I am assuming
[05:19] <nenolod> nixternal: shadow packages, and policies. copy-on-write, and rollback would have to be implemented into Dpkg.
[05:19] <nixternal> migration is an appliance developers best friend
[05:19] <nixternal> yay shadow pkgs
[05:20] <nenolod> rollback wouldn't be terribly hard, especially if COW was working
[05:20] <nenolod> dpkg is a lot more resilient to faults than RPM as it is, so i guess it is not seen as important
[05:20] <nenolod> but it would be cool ;)
[05:21] <nixternal> rollback would be much better if dpkg only applied changed files
[05:21] <nixternal> instead of complete binaries
[05:21] <nenolod> well, sadly that would require querying a server
[05:21] <nenolod> probably not going to happen :P
[05:22] <nenolod> or some obnoxious package format resembling xdelta on crack
[05:22] <nenolod> oh wait, that's what conary changesets are :P
[05:22] <nixternal> hahhaa, I was just gonna bring up xml/xdelta/and some other stuff
[05:22]  * ajmitch hasn't really followed what is different & special about that stuff
[05:22] <nenolod> i played with foresight and found conary to be quite inspiring
[05:23] <nenolod> however, conary does a few things wrong, like depending on external servers to find out what deltas to pull
[05:23] <nixternal> ajmitch: conary & rPath is appliance centric, whereas every other os is server/desktop centric
[05:23] <ajmitch> nixternal: nice sound bite, now explain it :)
[05:23] <nixternal> Ubuntu is trying with JeOS, but they have to get rid of that crap kernel and come up with a fully automated kernel editor/config/builder
[05:23] <nenolod> nixternal: i think some concepts from conary could be applied to dpkg and apt
[05:23] <nixternal> nenolod: +100
[05:24] <nenolod> however, debian will never be a good platform for appliances unless debian-installer gets a total overhaul
[05:24] <nixternal> well, I will disagree on that....d-i with FAI totally rocks
[05:25] <nixternal> but d-i with pxe and kickstart can be a pita
[05:25] <nenolod> well, the way i had in mind is quite simple
[05:25] <nixternal> I should say kickstart is the d-i pita there
[05:25] <persia> Also, vm-builder does a nice job for virtual applicance
[05:25] <nixternal> rBuilder ftw :)
[05:25] <nenolod> basically, you have your base system repo
[05:25] <nenolod> and then you have override repos
[05:25] <nenolod> which provide policy packages, shadow packages, etc
[05:26] <nixternal> I can select iso for app or vm, or I can select a vmware/vbox/qemu image from a drop down
[05:26] <nenolod> if it were done this way, ubuntu could reduce the diff between debian
[05:26] <nixternal> same thing I deal with utilizing CentOS for an appliance
[05:27] <nixternal> I have a super nasty rsync script that will check for changes, and move the changes to a temp file until they can be researched, tested, and then included
[05:29]  * nixternal kicks maven in the arse and goes back to ant
[05:35] <persia> nixternal: See https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec about maven: it's not suitable yet (although if you'd like to work on it...)
[05:36] <nixternal> haha, nevah!
[05:36] <nixternal> it sucks in Fedora, Red Hat, CentOS and *
[05:36] <nixternal> once it is mature and a hell of a lot less confusing, it will be good stuff
[05:36] <nixternal> but ant just works and works easily to be honest
[07:14] <porthose> ScottK: ping
[07:17] <NCommander> persia, poke
[07:18] <persia> NCommander: I'm just heading off: please be quick (and please provide content next time, or I may ignore the poke)
[07:18] <porthose> ScottK: when you have some time would you take a look at bug #263405 for me please?
[07:18] <porthose> It's an FFe for ampache.
[07:18] <NCommander> persia, if I provide a contextless poke, it usually means I just want to chat, no specific note to leave ;-)
[07:19] <NCommander> persia, so cya ;-)
[07:20] <porthose> ScottK: If I give a slow response it's probably because I fell asleep in my chair, it's quite late for me =)
[07:20] <superm1> kirkland, we're rolling some test disks tonight and that bug was keeping them from rolling.  i uploaded myth tonight, and will upload again after I see your patch okay?
[07:36] <dholbach> good morning
[08:07] <iulian> Good morning Daniel!
[08:23] <dholbach> hey iulian
[08:32] <stefanlsd> Im looking at the net pidgin 2.5.1 and there is a debian/libpurple0.symbols file - how do i check this is still correct? anyone able to help me understand symbols or can point me to some documentation on understanding them?
[08:33] <stefanlsd> I have this - https://wiki.ubuntu.com/PackagingGuide/Recipes/CheckingLibrarySymbols   (not sure that this is entirely the same thing thou)
[08:38] <verwilst> stefanlsd: ah packaging pidgin 2.5.1 for intrepid? ;)
[08:38] <stefanlsd> nodnod
[09:08] <huats> morning everyone
[09:13] <verwilst> stefanlsd: cool ( im a subscriber @ bugreport, that's why i asked :) )
[10:19] <Coper> LP:263074 should this one be synced to intrepid or is it too late?
[10:22] <Hobbsee> Coper: it'll need a FFe, but that sounds like a good candidate to get synced.
[10:22]  * Hobbsee notes people like ScottK might just poke it through
[10:32] <verwilst> isnt there some launchpad firefox plugin?
[10:32] <verwilst> for the search bar?
[10:32] <verwilst> so you can just type in the number in be directed the the launchpad page
[10:34] <Hobbsee> there is for debian.  not sure on ubuntu
[10:34] <Hobbsee> you could create one, or just create a bookmark that works.
[10:34] <Hobbsee> ie, lbp <number> expanding to the correct bug.
[10:36] <liw> is "smart bookmark" the appropriate term in firefox? (that's what the similar thing in epiphany is called, at any rate)
[10:53] <verwilst> there, made one myself :)
[10:53] <verwilst> somebody wants it? :)
[11:03] <Coper> Hobbsee: okey so I can create a debdiff for that package and submit to the bug?
[11:04] <Hobbsee> Coper: why would you be creating a debdiff, if it was a sync?
[11:04] <Hobbsee> (or is that the new procedure for ffe's now?)
[11:05] <Coper> I don't have the process clear to me how a sync is working.. How is making a sync?
[11:05] <Coper> Who*
[11:12] <stefanlsd> Coper: Your two options for getting a package from Debian into Ubuntu is - Sync or a Merge
[11:13] <stefanlsd> For both of these, you file a LP bug requesting a Sync or a Merge
[11:13] <stefanlsd> you need to determine if what you are trying to do is a sync or a merge
[11:13] <stefanlsd> A sync will be if the debian package will work exactly as is in Ubuntu and no Ubuntu changes are required in the package.
[11:14] <stefanlsd> We see this by packages in Ubuntu that are  package-ver-1  for example.
[11:14] <stefanlsd> If we see a package in Ubuntu package-ver-1ubuntu1  we know there are Ubuntu changes.
[11:14] <Coper> okey so in this case it's just a sync becurse we dont have any ubuntu versions of it.
[11:15] <stefanlsd> When then have to decide, are the changes that Ubuntu did specifically to the package still necessary to keep it an Ubuntu version. If they are, we need to merge. Else we file a sync bug.
[11:15] <stefanlsd> Ideally, any changes we make to Debian packages to make an ubuntu1 version, are given back to Debian, so next time we sync or merge, we can sync.  We always want to try stay as much as possible in line with Debian, else we just make lots of work for ourselves
[11:16] <stefanlsd> Coper: Yeah, if it was originally a Debian version and we made no changes, we will sync.   Being in FF at the moment, we need to make sure the sync fixes bugs and doesnt introduce new features.
[11:16] <directhex> of course, Ubuntu Main can complicate the whole sync thing. but for universe, go for it if you can
[11:17] <stefanlsd> If that is the case, you can apply for a Freeze Exception - https://wiki.ubuntu.com/FreezeExceptionProcess
[11:29] <POX_> devfil: ping me when you will need a sponsor for #490586
[11:30] <devfil> POX_: #490586 ?
[11:30] <POX_> http://bugs.debian.org/490586
[11:31] <devfil> POX_: ah ok, it is a sort of alpha for now, I'm awaiting for a release more stable
[11:31] <POX_> ok
[11:32] <devfil> s/awaiting/waiting/
[12:32] <torkel> should sync requests be subscribed to anyone special?
[12:33] <siretart> torkel: I'd suggest the sponsoring queue, if you are not a developer
[12:33] <torkel> nope. I'm not.
[12:34] <jpds> torkel: Using "requestsync" (in intrepid) shall automatically subscribe team for you.
[12:35] <jpds> the necessary team*
[12:36] <torkel> jpds: I used lp to file a bug (#264303) :-(
[12:36] <porthose> torkel: you will probably need and FFe also https://wiki.ubuntu.com/FreezeExceptionProcess
[12:37] <jpds> torkel: Looks good, might want to use the script next time tho.
[12:37] <torkel> porthose: why? It's not a new upstream version, just a new debian revision
[12:38] <porthose> ahhh ok
[12:39] <torkel> jpds: yeah. There are too many fancy tools to remeber them all though. Especially when you only do random requests
[12:41] <balachmar> Hi, I cannot install python-dev on 8.04 because of unmet dependencies: http://paste.ubuntu.com/43010/
[12:41] <torkel> it's ubuntu-universe-sponsors I should subscribe? Right?
[12:42] <slytherin> torkel: is the package in universe?
[12:42] <torkel> yes
[12:42] <slytherin> balachmar: any chance the mirror is not in sync yet
[12:42] <slytherin> torkel: then yu are right
[12:43] <torkel> slytherin: thanks :-)
[12:44] <persia> bug #264303
[12:44] <persia> torkel: No need for a freeze exception for that sync.
[12:44] <balachmar> slytherin: Well I selected the main server and it doesn't install
[12:45] <slytherin> balachmar: I don't have a hardy installation right now, so can't help much
[12:46] <stefanlsd> persia: do you know anything about symbols?
[12:46] <persia> stefanlsd: Some.  What do you need to know?
[12:47] <stefanlsd> persia: Im trying to understand why they are needed. Is it for debug purposes?
[12:48] <persia> stefanlsd: Please define "symbols", as there are many possible answers to your question, depending on what you mean.
[12:48] <balachmar> slytherin: too bad. I'll check my sources.list again
[12:49] <stefanlsd> persia: im looking at pidgin 2.5.1 and we include debian/libpurple0.symbols.  dh  runs dpkg-gensymbols and makes a diff (not sure sure between what exactly, or how dpkg-gensymbols gets them).  Im trying to work out, why we even need these symbols, as its not in every package
[12:50] <stefanlsd> persia: the package builds and im running it fine, im just trying to work out what i'm missing...
[12:50] <persia> stefanlsd: OK.  Those are the library symbols.
[12:51] <persia> Essentially, when creating a library, we need to have a set of names (symbols) to call each of the exported functions, and we need to let programs that use the library use the same symbols to identify what they want the library to do.
[12:51] <balachmar> I have turned of all extra repos and now I can select force version, but it doesn't force the version! ...
[12:52] <balachmar> The python version was from hardy-proposed and has been pulled from hardy proposed (As I am told)
[12:53] <stefanlsd> persia: ok. and the names may change in the library. like libpurple0 may have a different symbol now for a function?
[12:53] <balachmar> But now it doesn't want to go to the original hardy-security version
[12:53] <persia> dpkg-gensymbols hunts down libraries, and creates a debian/symbols file : this file is then used to better identify the versioned dependencies of a program using the library (from ${shlibs:depends}
[12:53] <persia> stefanlsd: Maybe.  Depends on how much the code has changed since it was last compiled.
[12:54] <directhex> balachmar, that's your problem
[12:54] <stefanlsd> persia: ok. that makes sense.  why do some programs use it, and some not?  Or will all libs use package.symbols?
[12:54] <directhex> balachmar, using -proposed is fraught with risk.
[12:54] <persia> stefanlsd: All libraries that export symbols (and a .so file) ought use it.
[12:55] <directhex> balachmar, look at the entire list of python-dev dependencies that it's moaning about, and use "aptitude reinstall fooapp=2.5.2-2ubuntu4.1" until all remnants of -proposed are gone
[12:55] <persia> It's mostly important for C and C++ programs, although some other languages also use this library format sometimes.
[12:55] <stefanlsd> persia:  https://wiki.ubuntu.com/PackagingGuide/Recipes/CheckingLibrarySymbols   - is this still current. Or is this now obselete with the introduction of dpkg-gensymbols.  and why cant we just use what dpkg-gensymbols finds for us?  isnt that its purpose?
[12:56] <persia> stefanlsd: That page becomes obsolete when every package providing a library uses dpkg-gensymbols, which I don't believe to be the case today.
[12:57] <persia> That said, it's worth doing some research and updating the page with a note about the use of the new system.
[12:57] <stefanlsd> persia: hehe. i would love to as soon as i get to the bottom of this :)
[12:58] <balachmar> directhex: I didn't know that is was that risky. Read somewhere that is was a good way to help out. With bug finding. But I wasn't aware that I could get into dependency traps...
[12:58] <directhex> balachmar, it IS a good way to help with bug testing... until someone finds one, and pulls a package from there
[12:58] <directhex> balachmar, then you're stuffed really
[12:59] <directhex> or at least need manual intervention
[12:59] <balachmar> directhex: As I am aware of now... :)
[13:00] <stefanlsd> persia: http://pastebin.ubuntu.com/43037/    - thats what dpkg-gensymbols wants to do.
[13:03] <stefanlsd> persia: does this mean i should be editing my debian/libpurple0.symbols accordingly?   Is dpkg-gensymbols to be trusted?  :)
[13:04] <stefanlsd> PS: A nice tip i got was to export DPKG_GENSYMBOLS_CHECK_LEVEL=4    which causes pbuilder to not complete if the symbols are broken :)
[13:13] <balachmar> directhex: Thanks for the help! I fixed it (and I will leave proposed off on my work machines..)
[13:28] <persia> stefanlsd: This means you should follow the advise on the wiki page, and make sure that you have the right symbols file.  I've not used dpkg-gensymbols myself, but suspect it may be correct, although if you're not sure of anything, it's always best to double check.
[13:28] <stefanlsd> persia: oki. thanks persia. that helped a lot.  If i can work it out, i will update the wiki page.
[13:56] <RainCT> is there some reason why DEB_INSTALL_DOCS_ALL works but DEB_INSTALL_EXAMPLES_ALL not?
[14:00] <slytherin> can anyone explain me why this is not a bug - bug #264283. I fail to understand Mr. Pedro's understanding.
[14:00] <soren> RainCT: Well, I can probably explain why DEB_INSTALL_DOCS_ALL works, but not so much why DEB_INSTALL_EXAMPLES_ALL doesn't.
[14:01] <directhex> slytherin, because in gnome land, you get one tick box and a thousand regist^Wgconf settings
[14:01] <directhex> AND YOU LIKE IT!
[14:02] <soren> slytherin: Ask pedro?
[14:02] <slytherin> directhex: I wouldn't mind it if it was the case with sound-juicer also. But sound juicer had a visible option, and rhythmbox does not have it.
[14:02] <slytherin> soren: will do the same.
[14:03] <soren> RainCT: DEB_INSTALL_DOCS_ALL is needed because cdbs has some files that it by default puts into each package (i.e. some files that it always wants to pass to dh_installdocs). It has no such thing for dh_installexamples.
[14:03] <directhex> slytherin, patches accepted!
[14:03] <slytherin> directhex: Surely, one it is accepted that it is a bug. :-P
[14:04] <soren> RainCT: It should be easy to add, though.
[14:05] <RainCT> soren: Ah, I see. Is there some other DEB_ thing for examples/changelogs/etc or do I have to use a debian/<whatever> file?
[14:06] <soren> RainCT: I'm not sure I understand the question. You can either use "DEB_INSTALL_EXAMPLES_binpackage1 = someexample" or put "someexample" in debian/binpackage1.examples.
[14:06] <RainCT> soren: ah, _<pkgname> works. Thanks for the info :)
[14:07] <soren> Any time :)
[14:10] <RainCT> soren: Do you also know how I can tell dh_pysupport to exclude some files (ie, I know that there's the -X option, but I can't use that directly because dh_pysupport is called by python-distutils.mk)?
[14:12] <soren> RainCT: There's no variable for that purpose right now, apparantly.
[14:21] <persia> RainCT: You could patch python-distutils.mk ...
[14:23] <stefanlsd> After updating the symbols - does anyone know why i would be getting lots of - dpkg-shlibdeps: warning: symbol whline used by debian/finch/usr/lib/gnt/irssi.so found in none of the libraries. errors and where i should be looking to correct these?
[14:23] <RainCT> persia: and ship the patched copy in debian/, you mean?
[14:25] <persia> RainCT: No.  Patch the regular python-distutils.mk to check for a variable definition, and pass -X with the variable contents if it is present.
[14:25] <persia> Then you make your package build-depend >= the updated provider of python-distutils.mk
[14:25] <persia> Remember, it's nice to share your bugfixes with others :)
[14:31] <bddebian> Heya gang
[14:32]  * wgrant drops dead.
[14:33]  * RainCT burns wgrant's body :P
[14:34] <bddebian> wow :)
[14:34] <persia> bddebian: Hey.  Can I beg you for an intrepid upload?  Just one?  Any package you like?  syncs count too?
[14:34] <bddebian> Heh, have something in mind?
[14:36] <persia> How about pushing some of the RC fixes you've been uploading in Debian into Ubuntu?
[14:38] <bddebian> OK, let me see if I can get a working Intrepid pbuilder going
[14:40]  * persia anxiously awaits the inevitable flood of uploads :)
[14:42]  * Hobbsee blames persia
[14:42]  * RainCT hugs persia 
[14:43]  * persia accepts both blame & hugs with equanimity
[14:43]  * \sh nos
[14:44]  * \sh needs to write to zend
[14:45] <persia> s/to//
[14:45] <\sh> 0
[14:46] <\sh> grmpf
[14:46] <norsetto> persia: needs write to zend :-P
[14:46] <\sh> why did they add the dojotools to the zend-framework tarball...but removed from the minimal the tests and docs
[14:46] <\sh> what source tarball should I use now for upgrading the ubuntu package...
[14:47] <DktrKranz> persia: open RC bugs in Ubuntu? With sebner around? I guess you'll have hard times finding some
[14:47] <persia> DktrKranz: bddebian is very creative.  He may close new RC bugs in Debian to achieve the goal :)
[14:48] <DktrKranz> bddebian: raise severity just for the sake to beat him! :)
[14:48] <bddebian> heh
[14:50] <norsetto> DktrKranz: welcome to the team :-)
[14:51]  * DktrKranz hugs norsetto, new collagues and persia
[14:51]  * persia is just a minor functionary, performing a delegated duty, and deserves no special thanks.
[14:53] <norsetto> persia: add badly paid to the list ...
[14:53] <persia> norsetto: Why?  I get paid just as much to be a minor functionary as you get to be a developer.
[14:54] <norsetto> persia: exactly; on the positive side we always can claim to have an 100% increase each month
[14:54]  * DktrKranz is looking for minimum wage, 10 euros/month will be better than no euros at all
[14:56] <norsetto> where is the bzr packaging fun? #ubuntu-classroom?
[14:57] <slytherin> soren: I asked pedro. Now he says I need to rephrase the summary. Now I am not sure what I should rephrase it to. :-(
[14:58]  * norsetto remembers too late that bddebian is strolling around
[14:58]  * RainCT tries to get his brain working again after helping his little brother with homework :/
[14:59] <norsetto> RainCT: do they still have those funny little problems about bath tubs filling with water?
[15:00] <soren> slytherin: Make it something like "library_strip_chars should be exposed in Rhythmbox' GUI"
[15:00] <slytherin> soren: I am sure he could do that himself. I don't understand why he asked me.
[15:01] <soren> Dunno
[15:01] <RainCT> norsetto: uhm? not sure what you mean, but afaik no :P
[15:02] <norsetto> RainCT: hmmm, not even those about the two trains leaving in opposite directions and when will they collide !?
[15:02] <RainCT> o_O
[15:03] <mok0> norsetto: It's at 18:00 on #-classroom
[15:04] <norsetto> RainCT: is your little brother not doing a major in astrophysics!?
[15:04] <norsetto> mok0: ah yes, thx
[15:04] <mok0> norsetto: hope to be there too :-)
[15:05] <norsetto> mok0: I don't know if hope is the right verb ;-)
[15:05] <mok0> hehe
[15:06] <mok0> norsetto: I think it could be cool, esp. if the build system could pull updates directly off bazaar
[15:06] <norsetto> mok0: what do you mean?
[15:07] <mok0> norsetto: Instead of you uploading a source deb, the build system could check out the most recent version from bzr and build it
[15:08] <mok0> norsetto: so merges etc could be maintained in bzr branches
[15:10] <norsetto> mok0: hmm, I still would want to see a "green light" lever being used
[15:10] <mok0> norsetto: heh, yeah
[15:10] <huats> norsetto !
[15:10] <mok0> norsetto: there are ways to do that with bzr afaik
[15:10] <norsetto> huats !!
[15:11] <norsetto> mok0: something like tags I guess, dunno, we shall see soon
[15:11] <mok0> yup
[15:19] <balachmar> There must be a few kvm users here. I have upgraded a vm to intrepid, but it seems unable to get into gdm. However I cannot use control+alt+F1 because of the grap. Howver the altgrab option is not supported in hardy? How can I get to another terminal?
[15:21] <stefanlsd> heh. learnt a ton about symbols today. I think i understand some of it and will try update the wiki with dpkg-gensymbols.
[15:27] <balachmar> nevermind, altgrab option is called differently than the normal qemu one. -alt-grab instead of -altgrab...
[15:28] <balachmar> However that doesn't get me into tty1 on the vm, the normal system still catches it...
[15:32] <sbalme> Is this a reasonable place to ask a general packaging question or can you point me elsewhere?
[15:33] <mok0> ! ask
[15:33] <RainCT> sbalme: you're right here :)
[15:34] <sbalme> Ok. I want to build a package containing a kernel module (a custom target for iptables) and I want it put it in a repository and install it on a bunch of machines. I can't see how to do this without requiring the machines recompile it themselves using something like module-assistant. Can I build a module package containing binaries for a particular kernel version?
[15:35] <Laney> Wasn't there a session on packaging kernel modules yesterday?
[15:35] <Laney> DKMS?
[15:37] <mok0> Yes that was yesterday, trying to find the log from that
[15:38] <mok0> sbalme: look here, around 19:00 and forward http://irclogs.ubuntu.com/2008/09/02/%23ubuntu-classroom.html
[15:38] <sbalme> Thanks, I'll check out both those things
[15:38] <mok0> sbalme: it's the transcript of the on-line tutorial last night on dkms
[15:39] <siretart> dholbach: as for your question on -motu 'what can we do in an ideal world to avoid serious disagreement on technical matters.': I think we cannot avoid that. What we can do however is to try to avoid excalating them too high by listening to each other
[15:41] <RainCT> how can I check if a variable is empty, in a makefile?
[15:41] <dholbach> siretart: do you think you can reply to the thread? I'll be in meetings and calls until the end of the day, so can't really reply well here on IRC
[15:41] <norsetto> siretart, dholbach : I'd say more, we can't have a serious technical disagreement, if its a (serious) disagreement its only a question of policy
[15:48] <norsetto> siretart: I always assumed you needed to be at least a motu to have upload rights to the archive
[15:53] <siretart> norsetto: in exeptional cases a per package upload right can be considered. at least this was discussed at the last UDS
[15:54] <norsetto> siretart: ok, I always read that as a motu for a "core" package, not as "somebody" for an ubuntu package
[16:00] <RainCT> persia, soren: about having a variable to exclude stuff from being byte-compiled, does it sound sane to you if it has to be defined before python-distutils.mk is included (like with DEB_PYTHON_SYSTEM)?
[16:00] <persia> RainCT: If you can have it be defined later, that's better.  Just use a definition in the include file that doesn't expand or test until runtime, rather than checking at parsetime.
[16:01] <persia> (remember, make has two flavours of variables, with entirely different semantics)
[16:01] <persia> IF you can't, then I guess beforehand can work.
[16:01] <persia> Personally, I find ?= to be fairly useful in make, as it's both runtime and only sets if unset.
[16:02]  * norsetto always gets an headache when persia talks about make
[16:03] <soren> persia: What are those two flavours?
[16:03] <persia> norsetto: If you want it to go away, read the make manual twice, and call me in the morning :)
[16:03] <persia> soren: variables defined at parse-time and variables defined at run-time.
[16:03] <persia> Basically, the difference between := and =
[16:04] <persia> (although there are other ways to set both runtime and parsetime variables)
[16:04] <laga> can someone please review my package on REVU? it just needs another ACK. i have two black cats and i will pet them if someone ACKs it. please makes the kittehs happy.
[16:04] <laga> http://revu.ubuntuwire.com/details.py?package=mythtv-theme-metallurgy-wide
[16:05] <persia> So, when one executes make on a makefile, it first sets all the parsetime variables, then it checks the rules it is asked to apply, then it checks the timestamps for the files represented by the rules, then it generates an execution map, and then it executes.
[16:05]  * persia recommends reading the results of make -p for the more curious.
[16:05] <soren> persia: Ah. I'm not sure I'd call that "entirely different semantics" :) I thought you were talking about magic control variables of some sort.
[16:06] <persia> soren: No.  magic control variables are always runtime.
[16:06] <persia> (and yes, make has *lots* of those)
[16:06] <soren> I meant even *more* magic ones :)
[16:07] <persia> Oh.  Those tend to be parse time, but most people don't usually use that sort of construction: it's usually reserved for internal implicit rules.
[16:07] <persia> And no, there aren't and extra magic variables, just magic variables and more magic variables.
[16:07] <persia> s/and/any/1
[16:08]  * persia has heard rumors that this terminology in make has something to do with a switch found on a computer at MIT
[16:08] <laga> haha
[16:08] <laga> if you use extra magic variables, it'll crash the box?
[16:08]  * RainCT is about to follow wgrant's example and die XD
[16:08] <persia> laga: There aren't any extra magic variables.
[16:09] <laga> ah, right. i misparsed that
[16:09] <laga> RainCT: before you do, make a cat happy and revu my package ;)
[16:09] <persia> It's just the magic variables, and the more magic variables.  The former are used to control flow depending on system state at runtime, and the latter are used to define meta-rules.
[16:10] <laga> persia: don't waste your time explaining this to me, my brain has turned into a mush after uni today
[16:11] <persia> laga: OK.  Read the make manual sometime.  You'll write debian/rules in a way that makes it extra clear it's not a shell script in the future.
[16:11]  * persia is particularly fond of $(_)
[16:15] <soren> persia: I don't think I'm familiar with that.
[16:15] <RainCT> ifneq ($(strip $(DEB_PYTHON_EXCLUDES)), )         - is this right?
[16:16] <persia> Looks good to me, but are you putting that within a rule, or around a definition?
[16:17] <RainCT> persia: there http://paste.ubuntu.com/43079/plain/
[16:18] <persia> RainCT: You need to not indent make conditionals: those will be interpreted as shell conditionals.
[16:19] <RainCT> uhm.. but it still doesn't work after unindenting the first stanza
[16:19] <persia> soren: Oddly, I'm not finding it in the manual.  I believe it's the path of the executing makefile.
[16:20] <sbalme> Thanks guys, DKMS looks like exactly what I need
[16:20] <persia> No, it's just $_  Hrm.
[16:21] <persia> Anyway, it works, despite not being in the manual :)
[16:21] <soren> $(_) should yield the same result, shouldn't it?
[16:21] <liw> isn't $x and $(x) for single-character variables identical in make?
[16:21] <RainCT> liw: yep
[16:21] <persia> Should be.
[16:21]  * RainCT is reading the variables section from the manual :P
[16:22] <RainCT> persia: may the problem with my code be that DEB_PYTHON_EXCLUDES is set before the first stanza, and that's why when it does the ifneq it's still empty?
[16:22] <persia> Anyway, I still don't understand why I can't find it in the manual.  It's incredibly useful when writing makefiles for /usr/bin/ that need to apply to the current directory.
[16:22] <RainCT> err s/before/after executing/
[16:23] <RainCT> if so.. how can I check if it is empty at runtime? (dh_pysupport gets angry if it gets -X without an argument)
[16:23] <persia> RainCT: Perhaps, but it's more likely because the conditionals are outside the rule, so they are being processed at parse time rather than at runtime.
[16:24] <RainCT> persia: that's what I meant :)
[16:24] <persia> Also, I'm fairly certain you didn't mean to use := if you are relying on later definition of a variable, as := forces definition at parse time.
[16:25] <RainCT> persia: ah yes, I'm just reading this. what should I use then, +=?
[16:26] <persia> RainCT: If you're extending the variable, yes.  If you are defining it, just = is probably good.
[16:29] <kirkland> superm1: ping
[16:30] <RainCT> persia: OK. So what do I have to do for the   ifdef DEB_PYTHON_SYSTEM    block to be executed at runtime?
[16:30] <kirkland> superm1: updated patch at https://bugs.launchpad.net/ubuntu/+source/mythtv/+bug/251325, backward compatible (tested) on my Hardy backend
[16:30] <kirkland> superm1: if you're happy with it, i can upload
[16:30] <persia> RainCT: Put it inside a rule.
[16:31] <RainCT> persia: like after the      $(patsubst %,binary-install/%,$(DEB_PACKAGES)) :: binary-install/%:      line?
[16:31] <persia> And don't use := and don't rely on anything that uses := and don't rely on more magic variables
[16:31] <persia> That would be the rule definition (you can tell because it ends in :)
[16:32] <kirkland> persia: could you add me to ubuntu-universe-sponsors?
[16:32] <persia> And don't indent your conditionals if you want them to be processed by make, rather than spawning shells.
[16:32] <persia> kirkland: Sure.
[16:32] <RainCT> persia: argh.. but if I place it there I get    /usr/share/cdbs/1/class/python-distutils.mk:249: *** commands commence before first target.  Stop.
[16:33] <persia> kirkland: Done.
[16:33] <kirkland> persia: thanks!
[16:34] <Yasumoto> Would anyone have some time to go over Python Dependencies, by any chance? https://bugs.edge.launchpad.net/ubuntu/+source/matplotlib/+bug/263608
[16:34] <superm1> kirkland, sure go ahead and upload it
[16:34] <superm1> i'll add it to bzr
[16:35] <persia> RainCT: What?  paste the snippet that causes that error.
[16:37] <RainCT> persia: http://paste.ubuntu.com/43081/plain/
[16:38] <persia> RainCT: You might want to indent the definitions, to match the previous code, no?
[16:39] <persia> Anyway, at this point, maybe it's getting too messy: perhaps just document that it must be defined at the top.
[16:41] <RainCT> but if I indent them I get "DEB_DH_PYSUPPPORT_ARGS: Command not found", because they are send to the shell, as you previously said. or am I missing something?
[16:44] <persia> RainCT: I don't think you're missing something.  I think that in this case, it would have to be a rule-specific variable defintion, using string manipulation functions, but I'm too tired and doing too many things simultaneously to explain in depth right now, so suggest you just get it defined before the include so you can do it at parse-time.
[16:49] <RainCT> persia: Alright, thanks.
[16:50] <kirkland> superm1|away: uploaded
[16:57]  * RainCT gives up after noticing that for DEB_PYTHON_EXCLUDES to work in all use cases a loop is necessary, as -X does only take one option :(. Abusing DEB_PYTHON_PRIVATE_MODULES_DIRS is easier.
[16:58] <soren> I was hoping you wouldn't discover that one :)
[16:58] <persia> RainCT: make also does loops, but one either has to do it inside a variable definition that gets parsed at runtime or through the definition of a new pattern of rules that becomes a dependency of a target.
[16:59] <persia> (well, there's also $(foreach), but that's arguably a hack anyway)
[17:02] <charliecb> hi all
[17:02] <charliecb> why is openoffice 3.0 not in ubuntu 8.10 ?
[17:02] <charliecb> can anybody tell me or send me a discussion-link for that topic?
[17:02] <liw> has it been released?
[17:03] <charliecb> liw: no, but firefox wasn't released at the release-date of 8.04
[17:04] <ScottK> charliecb: Read the archives of ubuntu-devel-disucss.  It's a completely orthogonal question.
[17:04] <RainCT> argh.. seems like -X only looks for the given string in the filename and not the path. /me kills himself
[17:05] <charliecb> ScottK: ok. thx
[17:56] <xxx__> hi
[17:56] <_iron> anybody took a look on http://www.cs.arizona.edu/people/justin/packagemanagersecurity/papers.html
[17:58] <ScottK> _iron: Some time ago.
[17:58] <kees> _iron: yeah, it's not a realistic problem for Ubuntu.  http://www.outflux.net/blog/archives/2008/08/20/ubuntu-security-repository-structure/
[18:00] <_iron> well
[18:00] <_iron> sounds good
[18:40] <balachmar> Hi, yesterday I followed the bug fixing session. And today I started looking at some "low hanging fruit" with harvest. However I have found very few easy pickings. Most of the easy pickings I have seen so far often deal with upstream bugs. However there isn't always a link to the bugtracker system. And other times it is stated that the bug should already be fixed in intrepid. So there is no real need in fixing it right? Basically
[18:40] <balachmar> I find it hard to judge whether or not to really try the patch.
[18:47] <cyberorg> tuxmaniac, ping
[18:48] <cyberorg> hi all :)
[18:51] <foxbuntu_vm> balachmar, what are you actually asking?
[18:53] <slytherin> cyberorg: he will be here in 15-20 minutes.
[18:54] <cyberorg> slytherin, ah thanks, The_Code and I needed someone to review packages
[18:54] <slytherin> cyberorg: which package?
[18:54] <cyberorg> The_Code, you have tarball, .dsc and everything somewhere accessible?
[18:54] <balachmar> I don't now really :) maybe some pointers on what to look for or something. Aah, I guess I'll just drop by tomorrow when I have time enough to actually discuss a bug here. Maybe just two bugs: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/258104 at the end it is said that it is already in Intrepid, so no action needed? And this one: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/258421 I think it is ubuntu specifi
[18:54] <balachmar> c, because of the blueprint, but I am unsure if this patch is really wanted.
[18:55] <cyberorg> slytherin, out GSOC project http://en.opensuse.org/Easy-LTSP
[18:55] <slytherin> cyberorg: why tuxmaniac specifically?
[18:55] <cyberorg> slytherin, i've met him personally :)
[18:55] <slytherin> oh
[18:55] <cyberorg> anyone who can help is great ;)
[18:55] <The_Code> cyberorg, in theory yes, tarball is not a problem, dsc and rules file are testing only not a real description there i need to edit them
[18:56] <cyberorg> The_Code, can you put them up on ftp?
[18:57] <The_Code> i will create a tarball with everything inside and upload iit
[18:57] <cyberorg> slytherin, you have the same mask as kl_eisbaer our opensuse-edu lead
[18:57] <persia> balachmar: In the case of 258104, if it's really fixed in Intrepid, it ought be marked Fix Released, and also nominated for hardy if you think it belongs in hardy.
[18:57] <slytherin> cyberorg: I bought it. :-)
[18:59] <persia> balachmar: In the case of bug 258421. you might want to catch tkamppeter on #ubuntu-devel and chat about the status.
[19:00] <ogra> The_Code, the tarball should not contain the debian dir and be called packagename-version_orig.tar.gz
[19:01] <The_Code> ogra it is now called easy-ltsp-0.5_080815.tar.bz2 cause it is the same as for the rpms
[19:01] <cyberorg> hi ogra :)
[19:01] <The_Code> btw hi ogra
[19:02] <The_Code> but if someone here will package it the package can be called whatever you like
[19:02] <persia> The_Code: Generally we prefer to review things pushed to REVU.  You can log in at revu.ubuntuwire.com (if you have an LP account), and just dput the package.
[19:03] <ogra> The_Code, its just important that the upstream tarball doesnt contin a debian dir
[19:03] <The_Code> ogra doesn't
[19:03] <ogra> no matter how you call it :) (a MOTU who wants to package it can rename it properly)
[19:03] <ogra> good :)
[19:03] <cyberorg> persia, we would like ubuntu maintainer for that :)
[19:05] <persia> cyberorg: Ah.  That's trickier :)  Generally, most of the Ubuntu maintainers encourage code to go into Debian.
[19:05] <The_Code> okay a tarball with the source tar and my dsc changelog rules and control file is here: http://forgeftp.novell.com/kiwi-ltsp/easy-ltsp-deb-rev.tar.gz
[19:06] <persia> That said, some prepare code to go through REVU, but typically only to meet some identified release goal that is important to them.
[19:06] <persia> What problem does your code solve?
[19:06] <sebner> norsetto: cool sesseion :D  learned some cool new things :)
[19:06] <The_Code> the source tarball is quite old
[19:06] <norsetto> sebner: I'm glad
[19:06] <The_Code> as it was the one i tried to build debs with
[19:06] <cyberorg> persia, http://en.opensuse.org/Easy-LTSP
[19:07] <sebner> norsetto: but somehow there weren't that many left at the end O_o
[19:07] <cyberorg> persia, and http://www.youtube.com/watch?v=NCDfnImh67E
[19:08] <norsetto> sebner: yes, they were all killed right at the beginning, guess 99% of the audience doesn't even know what a debian dir is
[19:08] <persia> cyberorg: I certainly don't have the time to package it (I'm behind on everything), but I was thinking that if you described it well, someone else might be interested.
[19:08] <persia> Other than that, pushing to REVU for a code review is probably your best bet.
[19:08] <sebner> norsetto: O_o, ok I wasn't attending packaging session because it is very basic but I think yours was easy too with some tipps and tricks :)
[19:08] <cyberorg> persia, well there is no GUI for ltsp's lts.conf configuration, this GUI fills that gap
[19:09] <persia> norsetto: On the other hand, you might offer that as a MOTU School session, as I suspect many active developers have never updated an upstream package.
[19:09] <norsetto> sebner: had I known about it I would have given a much simpler one
[19:09] <sebner> DktrKranz: \o/
[19:09] <norsetto> persia: I have no problem to give lectures, but I really would like to push new blood to come forward ;-)
[19:09] <persia> cyberorg: Erm.  That sounds like it's very likely to be a policy violation (about one package never changing a conffile of another package).
[19:10] <persia> norsetto: Indeed :)
[19:10] <DktrKranz> we sebner!
[19:10] <sebner> norsetto: what about pushing old blood forward? :P
[19:10] <cyberorg> persia, this GUI is just for that conf file
[19:10] <ogra> persia, lts.conf is nonexistent in the ltsp packages
[19:10] <sebner> DktrKranz: congratulations old man :P
[19:10] <norsetto> sebner: old blood should be disposed of (possibly gracefully)
[19:10] <DktrKranz> sebner, congratulations for being old?
[19:10] <ogra> it is no conffile as long as easy-ltsp edits the version in the tftpboot dir only
[19:11] <persia> Oh.  Cool.  Then it's not dead at the start, and has a good chance.  GUIs are good :)
[19:11] <sebner> norsetto: xD
[19:11] <ogra>  /var/lib/tftpboot/ltsp/$arch/lts.conf gets copied over /etc/lts.conf at boot of a thin client if it exists ...
[19:11] <sebner> DktrKranz: being in motu-release makes you wise and somehow old :P
[19:12] <ogra> lts.conf is essentially a basic .ini file with sections and variable=value groups
[19:12] <DktrKranz> sebner, being in motu-release makes me dangerous
[19:12]  * norsetto goes to have dinner
[19:12] <sebner> norsetto: hf
[19:12] <sebner> DktrKranz: for whom? :P
[19:12] <DktrKranz> Y O U
[19:12] <sebner> hrhr
[19:12]  * sebner won't file that many FFe like last cycle
[19:13] <laga> too bad the MOTUs hate cats :/
[19:13] <DktrKranz> oh, a good way for sebner to take some rest is frightening him
[19:13] <cody-somerville> I love CATS
[19:13] <sebner> laga: !?!
[19:13] <cody-somerville> I have a cat in my arms right now
[19:13] <sebner> cody-somerville: xD
[19:13] <sebner> DktrKranz: I don't understand?
[19:14] <laga> sebner, cody-somerville: i promised to pet my two cats if someone reviews my package on REVU but it didn't happen, therefore i conclude... ;)
[19:14] <cody-somerville> : O
[19:14] <sebner> laga: ^^ hehe
[19:14] <laga> if i had a camera, i could take pictures. hum.
[19:14] <cody-somerville> didn't we hit feature freeze already?
[19:15] <sebner> cody-somerville: yep
[19:15] <laga> cody-somerville: yes, but it's artwork and it's for mythbuntu and it'd get a FFe anyways and the cats are black
[19:15]  * cyberorg gets going
[19:16] <cyberorg> if anyone want to know anything about easy-ltsp for packaging ping me in #ltsp, 'night
[19:16] <The_Code> or ping me
[19:17] <ogra> The_Code, did you file a "needs packaging" bug ?
[19:17] <ogra> so people not around are aware of the opportunity ?
[19:17] <The_Code> not yet but will go to launchpad and add it
[19:18] <ogra> thanks :)
[19:18] <The_Code> i have to thank you ogra
[19:18] <ogra> nah, your wrote the app :) i just pointed in the right direction for a proper package :)
[19:25] <peepsalot> not sure if this is the right place to ask, but is there any way I can get subversion(svn) client 1.5 installed on hardy
[19:28] <foxbuntu_vm> peepsalot, not even close to the right place...go check out #ubuntu
[19:30] <peepsalot> yeah the thing about that channel is that nobody knows anything
[19:36] <sebner> \o/ joaopinto
[19:36] <sebner> \o/ jono
[19:37] <RainCT> peepsalot: Version 1.5 is available in Intrepid. You can either get the .deb from http://packages.ubuntu.com and see if you can install it, or get the source and build the package for Hardy yourself.
[19:38] <peepsalot> thanks, RainCT
[19:39] <sebner> is debian bugs page down?
[19:44] <persia> sebner: Was for me, but the Google Cache tends to be pretty good for the BTS.  Just check the last date on which the bug was cached.
[19:45] <sebner> persia: kk, thx
[19:52] <devfil> nixternal: ping
[19:52] <nixternal> yo
[19:52] <devfil> nixternal: If I'm not wrong your +1 on my application is the third, so am I a MOTU?
[19:53] <laga> oh
[19:53] <laga> confetti!
[19:53] <nixternal> if it is #3, then you are on your way...someone has to do the work now to make it official
[19:55] <sebner> devfil: can't wait, hmm? ^^
[19:55] <devfil> sebner: yes, I want only to know the status ;)
[19:56] <sebner> ^^
[19:56] <devfil> sebner: I'm waiting *your* MOTU application :P
[19:56] <sebner> devfil: luca doesn't have to time to cheer so I'll apply in 1 year :P
[19:56] <laga> devfil: i offer the unique opportunity for you to ACK your first package ;)
[19:57] <devfil> laga: LOL
[19:57] <laga> devfil: i will pet two cats in exchange for it.
[19:57] <laga> i might even take pictures.
[19:57] <devfil> sebner: He will find time to kill you if you odn't apply....
[19:58] <sebner> laga: do you have a whole bunch of them, he?
[19:58] <laga> sebner: packages or cats?
[19:58] <sebner> devfil: ^^, no stress
[19:58] <sebner> laga: cats, all of us have tons of packages
[19:58] <laga> i have two cats ;)
[19:59] <laga> (package is mythtv-theme-metallurgy-wide. will post pictures)
[20:00] <sebner> laga: don't you want to keep your cats? ^^
[20:00] <laga> sebner: i do. i never said anything about giving them away. look up "to pet" on leo.org ;)
[20:00] <DktrKranz> sebner, I have nothing to do, but I will be buried to do something else (invented) to avoid your application :)
[20:01] <sebner> laga: rofl rofl rofl
[20:01] <sebner> DktrKranz: haha :)
[20:02] <sebner> DktrKranz: maybe it's my destiny to remain u-u-c forever \o/
[20:02] <DktrKranz> sebner, I guess so, have fun
[20:02] <sebner> DktrKranz: Well, you have the fun reviewing my work ^^
[20:03] <devfil> sebner: and to be intimidated until the day when you will send the email...
[20:04] <sebner> devfil: In this case: My system is b0rken and I can't sent any mails :P
[20:04] <DktrKranz> sebner: I hereby promise I won't touch bugs you just comment or open in your browser
[20:05]  * sebner needs a new nick change
[20:05] <sebner> ^^
[20:05] <sebner> morning afflux :)
[20:05] <devfil> sebner: He will do, he had done the same thing to me....
[20:05] <norsetto> DktrKranz confirmed his first FFe, yuppie!
[20:05] <afflux> morning sebner
[20:05] <DktrKranz> norsetto, erm... my first two :D
[20:05] <sebner> devfil: I think he does since a month to me xD
[20:05] <sebner> DktrKranz: uhh, congratulations! :D
[20:06] <devfil> norsetto: o/
[20:06] <devfil> s/had/has/
[20:07]  * DktrKranz is off... c u later or tomorrow
[20:07] <sebner> DktrKranz: bye :)
[20:07] <sebner> wb mok0 \o/
[20:39] <norsetto> hi devfil
[21:30] <stefanlsd> https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols
[21:30] <stefanlsd> If anyone has some comments on my trying to understand symbols
[21:50] <persia> stefanlsd: Nice summary.  I'd recommend running it by sistpoty if you can find him wearing his MOTU School Professor of Library Packaging hat (he's away this week, but ought be back next week or so), and then adding it to the general packaging docuementation.
[21:51] <stefanlsd> persia: thanks persia.  Will do. I suspect i have some stuff wrong (some assumptions made) - so would really like him to just check what im saying isnt too misleading.
[21:52] <stefanlsd> will catch him when he is back :)
[21:52] <persia> stefanlsd: Also, while I think what you've written is likely correct in this specific case, I'm not confident enough to know how it ought get adjusted to use this case as an example of the general case.
[21:53] <stefanlsd> nodnod. me neither.  before this morning i didnt know anything about symbols :)
[21:53] <stefanlsd> and i think now i know   nothing + a bit
[21:55] <persia> stefanlsd: It's a fair bit.  You at least seem to be able to read the output of objdump.  Have you also looked at nm?
[21:55] <persia> If not, you might want to read the transscript of one of sistpoty's sessions.
[21:57] <stefanlsd> persia: yeah, thanks. never looked at nm. I will def. find some of his sessions.  I'm getting behind on stuff!
[21:58] <persia> stefanlsd: There should be links to transcripts, or possibly even reformatted documentation under https://wiki.ubuntu.com/MOTU/School
[22:00] <stefanlsd> persia: https://wiki.ubuntu.com/MOTU/School/LibraryPackaging  - yeah. great. thanks. I will go through this stuff tomorrow.  off to sleep :)
[22:00] <persia> stefanlsd: That sounds like a good idea :)
[22:01] <stefanlsd> I see slangasek is also clued up on libs (he actually helped in the implentation of dpkg-gensymbols in dpkg)
[22:03] <persia> He is *massively* knowledgeable about libraries, but perhaps for that reason, is someone for whom you want to save the questions that nobody else can answer :)
[22:03] <stefanlsd> nodnod.  I suspect he is pretty busy in his current role.
[22:04] <persia> Anyway, it's late.  Chat with you another day.
[22:04] <stefanlsd> yeah. night guys
[22:31] <NCommander> ScottK, ping?
[22:32] <ScottK> Pong
[22:32] <ScottK> Get my FTBFS fixed?
[22:32] <ScottK> NCommander: ^^
[22:33] <NCommander> ScottK, yup
[22:33] <ScottK> Great.
[22:33] <NCommander> Took awhile since I had to test build it on two architectures
[22:33] <NCommander> (had to make sure the fix didn't blow up on x86 :-))
[22:33] <ScottK> I like hearing about that kind of persistence.
[22:33] <ScottK> Yes.
[22:33] <NCommander> Actually, then it went to my PPA
[22:33] <NCommander> Still wasn't sure if it was going to still compile on x86
[22:33] <NCommander> (it does)
[22:34] <ScottK> Would you please make a bug and attach a debdiff?  I'll sponsor it after the alpha 5 freeze is over.
[22:34] <NCommander> Sure
[22:34] <NCommander> no proble
[22:34] <NCommander> *problem
[22:34] <ScottK> Thanks.  Just assign me to the bug.
[22:41] <NCommander> ScottK, what's your LP ID?
[22:41] <ScottK> kitterman
[22:43] <NCommander> ScottK, you got bugs
[22:43] <NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/indi/+bug/264504
[22:44] <ScottK> Thanks.
[22:44] <NCommander> ScottK, just make sure you check all the KDE packages and retry them if necessary
[22:45] <NCommander> (that should be 'fun')
[22:47] <ScottK> It's just one.
[22:47] <ScottK> kdeedu
[22:51]  * RainCT is wondering why there's "nl" and "cat -n" </random_comment>
[22:56] <nhandler> Does a patch that fixes a spelling mistake in an application require a Freeze Exception, or would it be allowed as a "bug fix only update"?
[22:56] <ScottK> nhandler: It's a bug fix, but ask yourself is it really worth maintaining that diff (not a significant issue if there's already an Ubuntu diff).
[22:57] <directhex> i'd wave it through as a "duh" update. but i don't get to make policy decisions on naming
[22:57] <ScottK> For things like this, I generally prefer to report it to Debian and wait.  Unless it's actually confusing, it's just not worth the added effort.
[22:57] <nhandler> ScottK: There is already an Ubuntu diff, so that is not an issue.
[22:57] <ScottK> That's not policy, just my preference.
[22:57] <ScottK> OK.
[22:58] <nhandler> ScottK: The package also has a debian revision of 0, and it has been fixed in the gnome svn
[22:58] <ScottK> nhandler: See if you can find any other bugs to fix in the package so it'll be worth the electricity on the buildd's.
[22:58] <ScottK> Ah.
[22:58] <ScottK> OK.  Debian/Gnome then.
[22:58] <ScottK> If I would even file a Gnome bug (not yet).
[23:04] <NCommander> nhandler, Devision Revisions of zero are rare, it only happens on NMUs ...
[23:05] <nhandler> NCommander: I said Debian revision, not Devision Revision. Which simply means that Ubuntu has a newer upstream version of the package than Debian, or the package is not in Debian yet.
[23:08] <NCommander> nhandler, oops, my mistake
[23:08] <NCommander> I've got to run, bbl
[23:08] <nhandler> Bye NCommander
[23:32] <slangasek> persia: did this libjna-java package get test-built?  I'm suspicious of seeing libx11-dev in Build-Depends-Indep.
[23:33] <slangasek> persia: especially when libjna-java is an arch: any package
[23:33] <directhex> maybe it only needs it for, um, good luck
[23:40] <bobbo> argh, Planet Ubuntu isnt picking up my new posts and I cant work out why :/