[00:48] <vorian> ScottK: awesome! thanks very much :)
[00:49] <Laney> Bah, can I use dh_installinit with an upstream provided init file? All the docs I can see need one in debian/
[00:56] <emgent> hi vorian good luke :)
[00:56] <vorian> thanks, same to you :)
[00:56] <emgent> hehe thanks :)
[00:58] <crimsun> RAOF: thanks
[01:00] <RainCT> TheMuso, \sh: bug 239719 is waiting for you when you have time to look at it (with minimal debdiff now) :)
[01:00] <RAOF> crimsun: No problem.
[01:11] <TheMuso> RainCT: Ok lookign now, since I'm in an SRU mode.
[01:12] <TheMuso> RainCT: Is this in intrepid?
[01:15] <TheMuso> RainCT: Why did you not include the changes to youtranslate and Makefile.youtranslate in a patch, as you did add a patch system...
[01:16] <TheMuso> Having some changes in the .diff.gz and some in a patch file doesn't make sense.
[01:16] <TheMuso> RainCT: ^^
[01:19] <RainCT> TheMuso: they are in a patch
[01:19] <TheMuso> RainCT: Um doesn't appear that way to me.
[01:19] <RainCT> TheMuso: 02_fix_ftbfs.dpatch
[01:19] <cody-somerville> jono, ping
[01:21] <RainCT> TheMuso: where are you looking?
[01:21] <RainCT> TheMuso: (and yes, those changes are in intrepid together with a new upstream version and many other packaging improvements)
[01:21] <TheMuso> RainCT: Sorry, I misread the patch.
[01:21] <LaserJock> cody-somerville: isn't it 1am in London?
[01:22] <TheMuso> RainCT: ACKing.
[01:22] <RainCT> TheMuso: great, thanks :)
[01:22] <cody-somerville> LaserJock, aye
[01:22] <TheMuso> RainCT: One change, hardy-proposed and not hardy
[01:24] <RainCT> TheMuso: argh, right
[01:24] <RainCT> I had to do something wrong :P
[01:24] <TheMuso> RainCT: heh
[01:24] <LaserJock> has anybody been thinking about building an Ubuntu PTS?
[01:26] <RainCT> LaserJock: what are you missing in LP?
[01:26] <LaserJock> quit a bit of stuff
[01:28] <emgent> hello people :)
[01:32] <LaserJock> RainCT: sorry, was afk
[01:32] <RainCT> np
[01:33] <LaserJock> things that come to mind are stuff from qa.ubuntuwire.com (unmet deps, FTBFS, NBS, etc.)
[01:33] <LaserJock> right now what I'd like is a package whiteboard too
[01:33] <LaserJock> so we can leave "notes" for each other
[01:34] <LaserJock> LP also doesn't track upstream versions
[01:34] <LaserJock> it would be good to have the Ubuntu version, Debian Version, and Upstream Version easily viewable
[01:35] <RainCT> LaserJock: Right. So basically an overview page for all the QA stuff affecting a single package
[01:35] <LaserJock> pretty much yeah
[01:35] <LaserJock> there would be a bit more than just QA stuff
[01:35] <RainCT> sounds useful
[01:35] <LaserJock> but a lot of it would be yeah
[01:39] <wgrant> LaserJock: I've often thought about building something like the PTS, but uni has grabbed me this holidays so my time is rather limited.
[01:40] <LaserJock> wgrant: I talked with ogasawara today and she seemed to want to work on something like that
[01:40] <LaserJock> and I've wanted to for a long time
[01:41] <wgrant> LP really should do it.
[01:41] <LaserJock> some of it
[01:41] <wgrant> But there's no chance of that until it's Freed.
[01:41] <LaserJock> even then
[01:41] <LaserJock> a lot of it is fairly specific to Ubuntu
[01:42] <LaserJock> I would like to see a package whiteboard in LP though
[01:42] <RainCT> well, good night guys
[01:42] <LaserJock> night
[01:43] <wgrant> LaserJock: That should be very easy to implement, and would be really useful... I wonder if they can be convinced to do it soon after 2.0.
[01:44] <LaserJock> wgrant: perhaps
[01:44] <LaserJock> like today I could have used it
[01:44] <LaserJock> Debian is currently trying to figure out a library issue
[01:45] <LaserJock> but in the mean time I don't want people merging or trying to "fix" dependent packages
[01:45] <LaserJock> it feels a tad weird to file a bug to have work *not* done :-)
[01:47] <wgrant> I've seen it done a number of times.
[01:47] <wgrant> "Don't merge X from Debian unstable"
[01:47] <LaserJock> it also implies that people actually look for those books
[01:47] <wgrant> Bugs?
[01:48] <LaserJock> bah
[01:48] <LaserJock> distracted, sorry
[01:48] <wgrant> I always do before I upload - I hope everybody else does.
[01:48] <wgrant> I've only clobber one contributor's merge before.
[01:48] <RAOF> Certainly for merges.
[01:48] <LaserJock> well, this isn't a merge
[01:48] <LaserJock> it'd be changing build deps
[01:49] <wgrant> Even so, people should be checking for other bugs they can fix in that upload.
[01:49] <LaserJock> *should* ...
[01:49] <wgrant> Right.
[01:49] <crimsun> well, if reasonably, yes.
[01:50] <crimsun> I didn't bother with several, e.g., flashplugin-nonfree.
[01:50] <crimsun> "closes foo, bar, baz, a, b, c, ..." is a bit tedious.
[01:52] <RAOF> Oh, thinking of which, I haven't done anything except upload to intrepid; it needs uploading to hardy-proposed, etc, right?
[01:52] <RAOF> Where 'it' is flashplugin-nonfree, obviously.
[01:53] <crimsun> RAOF: I'd hold off on that.
[01:53] <wgrant> Flash 10?
[01:53] <RAOF> Yay!  Less work.
[01:53] <crimsun> there's no confirmation that beta 2 resolves any of the security issues currently present in hardy's.
[01:54] <RAOF> Beta2 does still manage to consume a core, though.
[01:54] <crimsun> yes, very effective DoS.
[01:55] <wgrant> So multicore is a good security measure!
[01:55] <RAOF> Less effective than gnash, which has a tendency to consume all memory.
[02:19] <emgent> ember: ping about wordpress
[02:20] <ember> emgent ?
[02:20] <ember> err.. i didn't saw sispoty comment
[02:20] <ember> i'm gonna have a look at it emgent
[02:20] <ember> thanks
[02:21] <emgent> ok nice, Thanks to you
[02:27] <emgent> argh stupid comment on dad main -.-
[02:27] <emgent> "school girls xxx"
[02:28] <ember> lol
[02:29] <emgent> i go to clean it.
[02:29] <LaserJock> emgent: I guess perhaps it'd get people to do more merges, but I'm pretty sure that's not the way we want to do it
[02:30] <emgent> :)
[02:31] <nxvl> \o\ <o\ <o> /o> /o/
[02:31] <emgent> nxvl: what is it ?
[02:32]  * nxvl dancing
[02:32] <nxvl> but it look more like steps :S
[02:32] <nxvl> looks*
[02:32] <emgent> lol, you are crazy :)
[02:33] <ajmitch> or someone with a drunken xml fetish :)
[02:33] <emgent> hahaha
[02:33] <nxvl> heh
[02:33] <nxvl> emgent: nop, i'm boried, i'm in classes
[02:37] <nxvl> got dammit, my class already ended and my girlfriend ends in an hour
[02:48] <Gralco> i don't understand why vimtutor isn't working for me
[02:51] <persia> I've got a couple build errors with "/usr/include/sys/syslog.h:88: error: 'NULL' undeclared here (not in a function)".  Would someone who has worked around this before be willing to give me a pointer?
[03:04] <RAOF> nxvl: Your girlfriend ends in an hour?  Man, what're you doing on IRC!? :)
[03:25] <emgent> RAOF: lol
[03:25] <nxvl> RAOF: classes
[03:26] <nxvl> she is already here!!
[03:26] <nxvl> im gone
[03:26] <RAOF> Yay!
[03:26] <nxvl> read you!
[03:30] <bddebian> Heya gang
[03:41] <cody-somerville> Heya
[03:41] <bddebian> Hi cody-somerville
[03:47] <emgent> heya bddebian cody-somerville
[03:49] <cody-somerville> lo
[03:56] <bddebian> Hi emgent
[04:15]  * mneptok staples cody-somerville to his thigh
[04:15] <cody-somerville> ack!
[04:16] <mneptok> happy canada day! (late)
[04:17] <mneptok> have a cold O'Keefe's served in a pewter toque!
[07:06] <\sh> bug #239719 acked ready for -proposed
[07:20] <dholbach> good morning
[07:24] <AstralJava> Morning.
[07:24] <dholbach> hi AstralJava
[07:25] <AstralJava> Hello dholbach! :)
[07:33] <nxvl> dholbach: you have make a lot of videos the same day, but they are being released periodically, don't you?
[07:33] <dholbach> over two days, but yeah
[07:33] <dholbach> hi DktrKranz
[07:33] <nxvl> so, they are more comming?
[07:33] <DktrKranz> hi dholbach
[07:34] <dholbach> I think one more
[07:34] <dholbach> for now
[07:37] <nxvl> :D
[07:37] <nxvl> they are really cool btw
[07:40] <dholbach> thanks a lot
[07:40] <nxvl> i always use them on my packaging jams
[07:45] <nxvl> they help me to give the participants a quick overview about the process
[07:45] <nxvl> and then start to do the same process step by step with them
[07:45] <nxvl> :D
[07:45] <dholbach> I'm very glad they're useful
[07:45] <dholbach> we should do some more of them as a team: http://wiki.ubuntu.com/MOTU/Videos
[07:46] <nxvl> i will be glad
[07:46] <txwikinger> cool
[07:46] <dholbach> and even if they're not in a camera+screencast format, having screencast only would be nice too, maybe with some mixed in audio
[07:47] <dholbach> luckily https://wiki.ubuntu.com/ScreencastTeam/RecordingScreencasts has some information about how to do that
[07:47] <nxvl> yeah, i can find a camera
[07:47] <nxvl> or
[07:47] <nxvl> as you say just do screencast
[07:47] <dholbach> with added audio it should be quite good
[07:47] <nxvl> dholbach: how do you find the idea of translating them?
[07:47] <nxvl> yeah, of course
[07:48] <dholbach> nxvl: I'm all for it!
[07:48] <txwikinger> translating can be difficult
[07:48] <dholbach> sharing the love
[07:48] <nxvl> with translating i mean record same process in spanish, not just edit the audio
[07:48] <txwikinger> you have to basically redo them 100%
[07:48] <txwikinger> you want to use the screen localised too in that case
[07:49] <txwikinger> or if you want to do it the easy way, you could just add subtitles
[07:49] <nxvl> well
[07:49] <nxvl> to read subtitles plus read the commands
[07:49] <nxvl> is quite hard
[07:50] <nxvl> dholbach: or you were thinking on editing the audio or writing subtitles?
[07:50] <dholbach> no, redoing them
[07:50] <nxvl> ok
[07:50] <nxvl> yes
[07:50] <nxvl> i find it better
[07:50] <nxvl> i will try to find some equipment this weekend
[07:51]  * dholbach hugs nxvl
[07:51] <dholbach> awesome awesome awesome
[07:51]  * nxvl hugs dholbach back
[07:51] <nxvl> now
[07:51] <nxvl> i need to sleep
[07:51] <dholbach> sleep tight :)
[07:51] <nxvl> i need to fight with php code on the morning
[07:51] <nxvl> btw
[07:51] <nxvl> i hate php
[07:51] <txwikinger> good idea (even I just got up) :D
[07:51] <nxvl> txwikinger: 2 am here
[07:52] <txwikinger> well.. I got up 5am this morning
[07:52] <nxvl> dholbach: we should write some documentation on "translating the videos" or "doing videos" to have kind of a standard
[07:52] <dholbach> nxvl: just add it to https://wiki.ubuntu.com/MOTU/Videos
[07:53] <nxvl> dholbach: but we can coordinate it by e-mail
[07:53] <dholbach> sure
[07:53] <nxvl> dholbach: yes, i mean, for more people to do them on their languages
[07:53] <dholbach> right
[07:53] <nxvl> i will send you and jono an e-mail this weekend with it
[07:53] <dholbach> alright
[07:53] <dholbach> thanks Nicolas
[07:53] <nxvl> have a good day!
[07:54] <dholbach> gracias
[07:54] <nxvl> dholbach: there is nothing to thank :D
[07:54] <nxvl> just a lot of love to give to new contributors
[07:54] <dholbach> exactly :)
[07:54] <nxvl> now i'm gone
[07:59] <Iulian> G'morning
[08:55] <slytherin> Can someone please clear xml-commons-external source from queue? I plan to upload batik 1.7 to revu today which requires xml-commons-external.
[08:57] <persia> slytherin: You want it processed from the source NEW queue?
[08:58] <slytherin> persia: Yes, that is what I meant. In case you didn't haven't yet yesterday's channel logs, I could build batik 1.7 successfully yesterday.
[08:59] <persia> slytherin: Right.  Only the archive-admins can do source NEW, and this isn't the best channel in which to contact them.  That said, source NEW is hard, as it requires full license checks, etc.  It's typically done last of the archive-admin tasks, in any time remaining.
[09:00] <slytherin> persia: Ok. I will upload to revu any way so that you or geser can review it throughly. I will add a note about xml-commons-external dependency.
[09:03] <persia> slytherin: Batik is a NEW package?  I thought we had it in the repos.
[09:04] <slytherin> persia: not a new package. Updated. But the package source needs to be repackages which was also case with 1.6. And I have added few patches for build to complete properly. So I thought revu is best place for review.
[09:04] <persia> slytherin: We do have it in the repos.  Please don't upload to REVU.  Please attach the debdiff to a bug (or a diff.gz if it is a new upstream version).
[09:05] <persia> slytherin: Yes, but you don't need two people: you can just put it in the sponsors queue as normal.
[09:05] <slytherin> persia: but then I will also have to upload the repackages source right?
[09:05] <slytherin> /repackages/repackaged
[09:06] <persia> slytherin: No, just the diff.gz.  You should encode the repackaging in debian/rules get-orig-source, and document it in README.Debian-source
[09:06] <slytherin> persia: It is already documented in README.Debian-source. I will see if I can encode it in get-orig-source. That is a bit harder.
[09:09] <slytherin> persia: Do you have any example repackaging encoded in get-orig-source? Please note that I also need to do 'svn export <certain url>' in this case.
[09:11] <RainCT> slytherin: adblock-plus, for example, has a get-orig-source where it does a "bzr export"
[09:11] <slytherin> RainCT: Cool. Thanks. I will take a look.
[09:45] <Riddell> Iulian: giver has no dependencies
[09:47] <Riddell> Iulian: bug 245431
[10:01] <Iulian> Riddell: Yes, I'm preparing an upload to Debian with the fix.
[10:02] <Iulian> Riddell: It should be in Debian in a couple of days and then we can sync.
[10:03] <Iulian> Riddell: I can also make an upload to Ubuntu right now with some fixes but I think we should wait for Debian.
[10:05] <Riddell> Iulian: cool, thanks
[10:07] <Iulian> Riddell: So, what do you prefer? Wait for Debian or prepare an upload to Ubuntu today?
[10:08] <Riddell> waiting is fine with me
[10:09] <Iulian> Riddell: Okay
[10:15] <sebner> huhu jono
[10:16] <sebner> dholbach: thanks for ACKing my syncs and sry for the inconvenience
[10:16] <sebner> DktrKranz: now the 200 are full ;)
[10:16] <sebner> huhu sistpoty|work
[10:16] <sistpoty|work> hi folks
[10:16] <sistpoty|work> hi sebner
[10:17] <sebner> morning afflux ;)
[10:17] <afflux> hi sebner :)
[10:20] <DktrKranz> sebner: the more you do the more I'll beat you when I catch you :D
[10:21] <wgrant> ScottK: Are you this SpecialK that I see uploading lots of backports?
[10:58] <norsetto> Laney: giving up on btx?
[10:58] <Laney> norsetto: Yes, I found some problems with the upstream code that make it too much work to include.
[10:59] <Laney> And that fact that the -config UI must run as root will surely make that one more difficult to accept too.
[11:00] <Laney> I think it needs a few more releases to mature before it'll be ready
[11:02] <norsetto> Laney: well, don't nuke it then, you may want to keep it there so that people know you are working on it, and once it will be ready you restart uploading
[11:03] <Laney> norsetto: Righto, just didn't want to clutter up the list
[11:03] <Laney> norsetto: Thanks for your review too, it helped me come to this conclusion :)
[11:03] <norsetto> Laney: I don't think thats an issue, check with sistpoty or RainCT on anyone else with the revu gang to be sure
[11:04] <norsetto> Laney: glad I could help
[11:10] <sistpoty|work> from df on spooky (revu's host): /dev/md0              70568272  30367488  36644336  46% /srv
[11:10] <sistpoty|work> so not a problem in regards to disk space atm :)
[11:12] <Laney> sistpoty|work: I was more thinking visual screen space, or if someone decided to review it ;)
[11:47] <RainCT> Laney: well, you can archive it, then it won't show up on the front page
[11:48] <RainCT> uhm.. that was a fast answer.. :P
[11:48] <sistpoty|work> heh
[11:48] <Laney> RainCT: Up to you, btnx and btnx-config. I'm not going to work on them for this upstream version at least so no point on them being on there unless somoene else takes it up.
[11:49] <RainCT> ok, done
[11:49] <RainCT> sistpoty|work: btw, REVU converts URLs into links now :)
[11:49] <RainCT> (in comments)
[11:49] <Laney> Thanks
[11:49] <sistpoty|work> cool RainCT :)
[11:57] <Laney> siretart: Is it OK to do the ffmpeg-free rebuilds?
[12:05] <Laibsch> Hi
[12:06] <Laibsch> I am trying to use pbuilder to verify correct build of a package
[12:06] <Laibsch> but it fails and I don't understand why, or rather where I am deviating from standard practice http://rafb.net/p/D7HXEU43.html
[12:06] <persia> Laibsch: Are you encountering an issue?
[12:06] <Laibsch> of course I am ;-)
[12:07] <Laibsch> Why does pbuilder want to call mknod?
[12:08] <Festor> 	
[12:08] <Festor> One question, I'm doing a package that does not exist in debian. I should use 1.2-0ubuntu1 or 1.2-1ubuntu1
[12:08] <Festor> ?
[12:08] <directhex> Festor, 0
[12:08] <Festor> ok, thanks
[12:09] <directhex> Festor, the X in XubuntuY refers to the debian revision - 0 for not-in-debian
[12:09] <Festor> then 1.2-0?
[12:10] <Laibsch> no
[12:10] <Festor> ehh
[12:10] <Laibsch> 1.2-0ubuntu1
[12:10] <Laibsch> AFAIK
[12:10] <persia> Laibsch: I believe pbuilder is to be run as root.  If you want to build without root access, you might investigate sbuild, which does the root bits in a user-invisible way (and with LVM, in a filesystem idempotent way)
[12:10] <Festor> but ubuntu1 is the debian revision, no?
[12:10] <Festor> and my package does not exist in debian
[12:10] <Laibsch> persia: One is supposed to build as root?
[12:10] <Laibsch> I find that hard to believe
[12:11] <Laibsch> How can I be sure not to f*ck up my system
[12:11] <directhex> Festor, it enables debian to take the package
[12:11] <Festor> ok
[12:11] <Laibsch> Festor: 0ubuntu -> not in debian (0), version 1 in ubuntu (ubuntu1)
[12:11] <Laibsch> Festor: 0ubuntu1 -> not in debian (0), version 1 in ubuntu (ubuntu1)
[12:11] <directhex> Festor, 0ubuntu1 means "this is the first ubuntu-specific version of a package with a debian revision of 0 (not at all)"
[12:11] <persia> Laibsch: Use sbuild+LVM to be sure not to affect the system.  pbuilder does a fairly good job, but as it's in the same filesystem, one can break out more easily than with sbuild+LVM.  That said, chroot is pretty good these days.
[12:12] <directhex> Festor, if debian adopts your package, then they start their numbering at 1
[12:12]  * Laibsch does not really feel like setting up an LVM just to build a package
[12:12] <Festor> then 1.2-0ubuntu0? or 1.2-0ubuntu
[12:12] <directhex> Festor, and since syncs are better than merges, you want the first debian version to supercede the first ubuntu version
[12:12] <Laibsch> ﻿(13:10:10) Laibsch: 1.2-0ubuntu1
[12:12] <persia> Laibsch: In that case, you need to trust pbuilder to behave.
[12:13] <Laibsch> Festor: you said it yourself
[12:13]  * persia only has ~20GB under LVM, not everything
[12:13] <Festor> sorry
[12:13] <directhex> Festor, your package is debian revision 0 (non existent), ubuntu revision 1 thereof (first version to exist)
[12:13] <directhex> Festor, so 0ubuntu1. see?
[12:13] <Festor> ok, ok, thanks for all
[12:14] <Festor> This package is a amsn plugin
[12:15] <Festor> If I want to send to Intrepid should I put a bug in amsn?
[12:16] <Festor> Forget, I am reading the wiki ubuntu
[12:22] <jcfp> is there a way to get dh_pysupport to also create optimized *.pyo files rather than just *.pyc?
[12:23] <persia> jcfp: It would require changes to python-support, as the compilation happens at install-time.
[12:24] <jcfp> persia: so there's not some easy switch to tell it to just do that
[12:24] <persia> jcfp: Nope.
[12:24] <jcfp> bummer. guess I'll have to use postinstall/prerm scripts then
[12:24] <persia> Or, at least not in dh_pysupport.  I don't pretend to actually understand the details of python-support: that might have such an option, which would apply system-wide.
[12:25] <persia> jcfp: You really don't want to do that.
[12:25] <lifeless> huh
[12:25] <jcfp> persia: any better way?
[12:25] <lifeless> I thought python-support did pyo files
[12:25] <jcfp> lifeless: only creates pyc here?
[12:25] <persia> jcfp: Let's look at this differently: why do you need optimised compilation?
[12:26] <persia> lifeless: There may be such an option, but it's not package-specific.
[12:26] <jcfp> persia: upstream suggested doing so may give better performance?
[12:26] <siretart> Laney: sorry?
[12:27] <Laney> siretart: I saw you requested the deletion of ffmpeg, was just wondering if it was OK to request rebuilds of the NBS
[12:27] <lifeless> interesting, no pyo's
[12:27] <lifeless> that will suck when bzr starts running with -O by default
[12:27] <persia> jcfp: I'm under the impression that the local .pyc files are customised for the system on which they are installed already, despite their extension.  Please benchmark with some local tests: if you can find a signficant increase, it may be worth looking into it more deeply.  Most likely, it won't matter.
[12:28] <persia> lifeless: You also might want to test: it may be that the python-support local compilation at install time is sufficient for your needs.
[12:28] <lifeless> persia: I think you are missing some context :)
[12:28] <jcfp> btw, there is /etc/python/debian_config but changes there dont seem to have any effect on dh_pysupport
[12:29] <lifeless> persia: bzr is looking at making 'bzr' run with python -O rather than plain python
[12:29] <lifeless> persia: this will cause .pyc files to not be used
[12:29] <lifeless> persia: and that matters because users cannot write .pyo files to /usr/lib, so every invocation will have to byte compile
[12:29] <lifeless> persia: -> slow
[12:30] <jcfp> lifeless: similar stuff here, upstream by default uses -OO in the program
[12:30] <siretart> Laney: oh yes, please do!
[12:30] <Laney> siretart: Excellent, will do!
[12:30] <lifeless> jcfp: unless they have significant memory use, or compiled pyc file size, it won't make much differnece
[12:30] <persia> lifeless: Ah.  You've already investigated it :)
[12:31] <lifeless> persia: well, more than I know some parts of pythons internals :)
[12:31] <persia> lifeless: investigating in 30 seconds from memory counts :p
[12:31] <siretart> Laney: I do expect some build failures. please file bugs with patches and tell me about them. thanks!
[12:32] <persia> Anyway, if there is sufficient need for .pyo, it might be possible to do that with the python infrastructure, but since it's all common, it means optimising everything, which may break some things, and may not be a win in terms of disk-sace vs. performance for others.
[12:33] <lifeless> persia: it won't break/unbreak things - because python -O will behave the same anyhow
[12:33] <lifeless> just whether it has to JIT compile it
[12:34] <persia> lifeless: But isn't JIT of .py when .pyc is available likely to not be much faster than using .pyc directly?
[12:34] <lifeless> persia: python -O disables .pyc, thats the point.
[12:34] <jcfp> am I correct in thinking that, in order to use the currently installed pyc files, python for that program must actually be run without any optimization options or it will try to create pyo (and fail at that) every time?
[12:35] <lifeless> persia: if .pyc is available it is a big win over JIT compiling the .py
[12:35] <lifeless> jcfp: yes
[12:35] <persia> By policy, .pyc ought be available for any .py in any module on an Ubuntu system.
[12:35] <persia> scripts aren't compiled by default, so it's best to have a small script to instantiate something in a module, for performance.
[12:36] <lifeless> jcfp: for instance:
[12:36] <lifeless> strace python -O -c 'import bzrlib'
[12:36] <lifeless> ...
[12:36] <lifeless> read(5, "\"\"\"distutils.errors\n\nProvides ex"..., 4096) = 3636
[12:36] <lifeless> read(5, "", 4096)                       = 0
[12:36] <lifeless> unlink("/usr/lib/python2.5/distutils/errors.pyo") = -1 ENOENT (No such file or directory)
[12:36] <lifeless> open("/usr/lib/python2.5/distutils/errors.pyo", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0666) = -1 EACCES (Permission denied)
[12:37] <lifeless> python is really quite unfriendly to system wide installs
[12:37] <jcfp> ayay ;)
[12:37] <persia> Between this confusing optimisation issue and the recommendation to use the cheeseshop, it's annoying in several ways.
[12:38]  * lifeless loaths eggs
[12:38] <Festor> If I want to send to Intrepid my amsn plugin package should I put a bug in amsn?
[12:38] <persia> The cheeseshop provides eggs?  I thought python was supposed to be intuitive.
[12:39] <lifeless> persia: cheeseshop often has setuptools based installer links
[12:40] <persia> lifeless: Yes.  That was intended as humor.  Perhaps I oughtn't try to send you emotional content over IRC...
[12:41] <lifeless> persia: irony and sarcasm need hints
[12:42] <persia> ..orz
[12:42] <Laney> Festor: needs-packaging bugs are usually filed against ubuntu
[12:43] <Festor> Laibsch, this is not a "needs-packaging"
[12:43] <Festor> I made the package
[12:43] <Festor> I have diff.gz and orig.tar files
[12:43] <Laibsch> ???
[12:43] <Laney> Is it already in the Ubuntu archives?
[12:43] <Festor> no
[12:43] <Festor> Is a new package
[12:43] <Festor> a plugin for amsn
[12:43] <Laney> Then you'll want to follow the REVU process
[12:43] <Laney> !revu
[12:44] <persia> Festor: It's a matter of perspective.  You believe that Ubuntu needs to package this application.  You're also doing the work.  That still means it ought get a needs-packaging bug.
[12:44] <Festor> ok
[12:44] <beDrung> dholbach: ping
[12:45] <jcfp> persia, lifeless: thanks for your input, made me a bit wiser again
[12:47] <porthose> slomo: thanks for the update :)
[12:49] <norsetto> porthose: any success with bzr?
[12:50] <porthose> norsetto: havn't tried yet today give me a sec and I will try
[12:51] <porthose> norsetto: still get the same error.
[12:51] <norsetto> porthose: have you seen my email?
[12:52] <porthose> yes
[12:52] <Laney> Rebuild requests which affect a few packages: One bug or one bug per package?
[12:53] <persia> Laney: Depends on how many.  For two or three quick hits, one bug is OK.  For large sets, for which the solution is not clearly obvious, multiple bugs is preferred.
[12:54] <Laney> persia: I imagine most of them will be no-change rebuilds. For anything more complex I'll file a separate bug. There are 26 source packages affected in all
[12:54] <persia> Laney: OK.  Are you sure you need a bug?  Will they appear in NBS?
[12:54] <Laney> persia: They already are
[12:54] <persia> Ah, you're providing the debdiffs for the rebuilds?
[12:55] <Laney> persia: Yeah, I have no other way of getting things done ;)
[12:55] <persia> 26 packages is still a lot of people to poke for an NBS thing though.  I'd try to avoid having a bug have more than 4-5 tasks for now.
[12:55] <persia> what are you NBS'ing?
[12:55] <Laney> It's ffmpeg->ffmpeg-free
[12:56] <persia> Right.  That'll hit a few package subscribers.  I'm not sure we have a good way to do this now that we agreed a bug with lots of affects is bad.
[12:57] <siretart> Laney: btw, we renamed it again from ffmpeg-free to ffmpeg-debian, but that package is currently sitting in debian NEW
[12:57] <persia> Anyone have any suggestions for how Laney ought submit the diffs?
[12:57] <persia> Laney: Based on the last comment: please wait :)
[12:57] <Laney> siretart: Will that cause a problem?
[12:57] <siretart> Laney: no, the binary packages have not been renamed, and it is unclear if we want to do that for intrepid
[12:58] <siretart> Laney: for pure rebuilds there is no real point in attaching a debdiff. just file a bug, and if you want attach a buidlog
[12:58] <siretart> buildlog
[12:59] <Laney> siretart: and subscribe the sponsors, right?
[12:59] <Laney> That makes it easier to script the rebuilds
[13:00] <siretart> script the re
[13:00] <siretart> 'script the rebuilds'?
[13:01] <Laney> If I just have to attach buildlogs instead of debdiffs then I can just rebuild them all locally and not have to worry about changelogs and such
[13:01] <Laney> So just loop over all directories and run sbuild in them
[13:01] <siretart> exatly
[13:05] <Laney> Right, that's going. I'll be back later everyone, have a nice day :)
[13:14] <porthose> norsetto:  going to start over from scratch, and follow the guide step by step (in case it's something I did wrong, which it probably is).  Thanks for the help :)
[13:14] <norsetto> porthose: np, I was just worried that I had to change something on the LP side, but couldn't find any way to do it ;-)
[14:05] <siretart> yay debian Bug #489236 :)
[14:07] <persia> Nifty!
[14:08] <sistpoty|work> well... we still need to do a release first, and I still got no clearance about the parser files :(
[14:08] <sistpoty|work> s/files/file/
[14:36] <slytherin> Can someone give back libspin-java?
[14:38] <sistpoty|work> slytherin: given back
[14:38] <slytherin> sistpoty|work: Thanks.
[14:39] <sistpoty|work> slytherin: np... that was the first time I hit that shiny new button :)
[14:40] <persia> slytherin: You saw that NEW was cleared, right?
[14:40] <slytherin> persia: No. I didn't. Thanks for letting me new. :-D
[14:40] <slytherin> s/new/know
[14:43] <dholbach> beDrung: pong
[14:44] <beDrung> dholbach: i have corrected the xmms2 package.
[14:44] <beDrung> dholbach: please have a look at it.
[14:44] <dholbach> beDrung: right, I'm subscribed to the bug and got a mail for it - I'll take a look at it later on - I'm busy with a bunch of other things right now
[14:45] <dholbach> but I'll get to it
[14:45] <beDrung> thx
[14:47] <DktrKranz> dholbach: it was you who had troubles with mouse in intrepid?
[14:48] <dholbach> DktrKranz: yes, but I fixed it
[14:48] <dholbach> DktrKranz: see the xserver-xorg-input-vmmouse changelog
[14:48] <quio> Can someone please help me get my wireless working.   I have been reading Ubuntu forums and documentation to get it running and cannot figure it out.  It worked before I upgraded to 8.04 hardy.  I know the card works because if I put in an XP hard drive it works right away.  Any suggestions please?
[14:49] <DktrKranz> dholbach: don't know if it's the same problem, but I'll check when I'll be back home
[14:50] <DktrKranz> thanks
[14:50] <RainCT> quio: please ask in #ubuntu, this channel is for development
[14:50] <dholbach> DktrKranz: now my intrepid kvm is happy again
[14:50] <DktrKranz> my real hardware a bit less :)
[14:51] <DktrKranz> mh... no. definitely not my issue :/
[14:55] <slytherin> when I write a get-orig-source target in rules file, how do I test it?
[15:02] <sistpoty|work> slytherin: make -f debian/rules get-orig-source
[15:03] <SWAT> I intend to package a game and want to get into the repository. Since I'm not an official maintainer, what is the best way for me to achieve this goal? Note: I also want this to go upstream.
[15:04] <slytherin> sistpoty|work: Oh, I thought I need to use uscan
[15:04] <slytherin> SWAT which game is it?
[15:07] <SWAT> slytherin: it's not in the repo's yet
[15:09] <slytherin> SWAT: What is the name of game.
[15:13] <directhex> SWAT, games are sometimes trickier to package than other apps, as often the art resources are not Free. we need to know which game it is
[15:50] <nxvl> dholbach: i have just replied you, can you please confirm
[15:54] <ScottK> wgrant: I'm not SpecialK, but his LP id is the same as my IRC nick, so a lot of my backports get attributed to him.
[15:55] <dholbach> nxvl: cool - I got it - thanks a lot
[15:56]  * nxvl hugs dholbach and runs
[15:56] <sebner> lol
[16:09]  * sistpoty|work heads home... cya
[16:16] <highvoltage> dholbach: howdy!
[16:17] <dholbach> hi highvoltage
[16:17] <highvoltage> dholbach: I did my first debdiff yesterday, thanks to you and the video
[16:17] <dholbach> NICE
[16:17] <dholbach> good work
[16:18]  * highvoltage is really happy about it
[16:18] <highvoltage> not sure what to do next though. should I just go through launchpad and fix bugs with debdiffs for now?
[16:19] <dholbach> sounds good - there's bitesize bugs too
[16:19] <dholbach> http://wiki.ubuntu.com/SponsorshipProcess explains how to get them included in Ubuntu
[16:19] <highvoltage> ok. it's one of the bitesize bugs I did last night. will hunt more of them down
[16:20] <dholbach> excellent
[16:20] <highvoltage> ( https://bugs.launchpad.net/ubuntu/+source/pyro/+bug/178948 , for what it's worth )
[16:21] <Laney> Has anyone used the massfile tool from u-d-t before?
[16:21] <Laney> I have no idea what the purpose of the buglist-url is
[16:22] <highvoltage> "1  → 20  of 65800 pages matching "bitesize packaging" "
[16:22] <highvoltage> omg, there's lots of work there!
[16:25] <Laney> highvoltage: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[16:26] <highvoltage> Laney: aah, thanks
[16:30] <jpds> Laney: good question, pity the source doesn't say who wrote it
[16:30] <highvoltage> I assume some of those bugs shouldn't really be 'fixed'? (bug 90434 as an example)
[16:31] <Laney> jpds: Yeah :( I think that any packages coming up on that URL won't have bugs filed again by massfile
[16:33] <jpds> Laney: according to the Debian changelog, dholbach added the script.
[16:34] <jpds> Laney: and /usr/share/doc/ubuntu-dev-tools/examples/massfile.instructions has an example of its usage.
[16:35] <Laney> jpds: Yeah, I've got that example. Couldn't see what the url was for without source diving though
[16:35] <Laney> ah well
[16:35] <Laney> (I accidently ran it twice and filed some bugs with that example too :()
[16:35] <jpds> "We Need Man Pages" :)
[16:37] <laga> yes
[16:44] <bliZZardz> in ftbfs, pbuilder is shown in RED for i386 and amd64 - am i missing something to read here or is this possible?
[16:51] <DktrKranz> \sh SRU-related stuff, any opinion on bug 186869? It was one of our biggest issues in the past
[16:52] <DktrKranz> (and it still is)
[16:54] <ScottK> DktrKranz: My suggestion would be it's not regression, data loss, or a crash.  Put it in backports.
[16:54] <\sh> DktrKranz: well, I would say: pushing to backports, testing there, and if there are no serious regressions, copy to -updates
[16:54] <ScottK> Upstream shipped a package that had very limited functionality is not an SRU criteria.
[16:55]  * ScottK disagrees, but wouldn't block it if others want to do it that way.
[16:55] <DktrKranz> I agree with ScottK here. This was my initial interpretation, since changes were very huge (as lool pointed out).
[16:56] <bliZZardz> ScottK : in ftbs list, pbuilder is in RED in both i386 and amd64 - is this fine or am i missing something?
[16:56] <\sh> ScottK, DktrKranz: well, tbh, I'm biased, because I have a problem with e.g. wireshark in dapper too...(regarding security that is...)
[16:57] <DktrKranz> \sh: need to backport a new upstream to fix it?
[16:58] <\sh> DktrKranz: wireshark in dapper? yes
[16:58] <ScottK> bliZZardz: It's right https://launchpad.net/ubuntu/intrepid/+source/pbuilder/0.181ubuntu3
[16:59] <\sh> DktrKranz: but regarding glom and gutsy: I would say, backports is the to go here...(regarding the EoL of gutsy)
[16:59] <\sh> insert "way" between "the" and "to" ;)
[17:00] <DktrKranz> \sh, I'm OK to backport a new upstream if it just ships bugfixes (e.g. startupmanager). We would introduce additional features which are hard to track.
[17:00] <ScottK> bliZZardz: It looks like that problem is that dblatex is not installable on Intrepid.
[17:00] <ScottK> DktrKranz: You're overloading the term backport.  Please pick a different word.
[17:01] <DktrKranz> s/backport/push in -proposed/
[17:01] <ScottK> Yes.  Backport has a specific meaning here that's something else ...
[17:02] <bliZZardz> ScottK : but pkgs using pbuilder for Interpid wouldnt be a problem(just thinking out loud)
[17:02] <\sh> DktrKranz: sometimes this isn't easy to say...I'm one of the kind who believes that a version which is totally not usable is bad for the distro...so having a version wich works is much better, and sometimes, I think, it's ok to push a "new upstream from a newer ubuntu release" through -proposed/-updates...but that's just me...
[17:03] <ScottK> bliZZardz: No, the binaries for the old version are still in the archive.  People can still use that in the meantime.  This is about building the pbuilder package, not using pbuilder to build packages.
[17:03] <DktrKranz> \sh, I never realized glom in gutsy was totally unusable or not. Looking at the comment, it sounds it lacks an important feature, but it's hard to tell what is important and what's not
[17:04] <\sh> DktrKranz: that's why I'm not deciding...if it was an app which I'm using everyday...then it would be different :)
[17:05] <bliZZardz> ScottK : got it.
[17:05] <ScottK> \sh: We have rules about what is good for SRU and I dno't think this qualifies.
[17:05] <DktrKranz> we should reach a decision, I think is worth having a package in -backports just to be able to say "it doesn't work? use the one in -backports", so at least we don't leave users alone
[17:05] <ScottK> \sh: We can discuss changing the policy, but we ought to stick with the one we have until that's done.
[17:06] <ScottK> There's a difference between 'doesn't work' and only supports a limited use case.
[17:06] <ScottK> The bug was filed 4 months after Gutsy's release, so either no one uses the package until then or it was doing something useful for a set of users.
[17:08] <ScottK> While we're on SRUs, I think motu-sru is gettung subscribed way to early in the process.
[17:08] <ScottK> I don't think we should be dealing with large numbers of end users wanting stuff fixed.
[17:08] <ScottK> I think motu-sru should get subscribed when someone has something the might want to upload.
[17:09] <laga> yeah, so people prepare debdiffs, test them only to have them rejected?
[17:09] <ScottK> No.
[17:09] <\sh> ScottK: as I said, it's my opinion...and I'm too busy to start a discussion about "versions which are known to not work are in need to have a newer upstream to be pushed through -proposed/-updates bla"...
[17:10] <ScottK> laga: More someone thinks they might want to fix it subscribes motu-sru and asks if it qualifies.
[17:10] <ScottK> laga: Dealing with large numbers of non-developers who want something fixed just doesn't scale very well.
[17:12] <\sh> ScottK: but I think the "glom" report was filed from murray, and murray is upstream ... no glom package in debian so far, so I think it's also fair to mention, that upstream wants a working version of his project in the distros...
[17:12] <ScottK> \sh: Sure.  My view is it's either not much used or working in a way that's useful for some users and so we shouldn't take on the regression risk.
[17:13] <ScottK> \sh: If upstream doesn't want broken stuff packaged, they shouldn't release broken stuff. ;-)
[17:13] <ScottK> I won't veto if others want it, but that's my opinion.
[17:14] <DktrKranz> ScottK: so, would it be fine to release to gutsy-backports and then take a decision if this is worth the regression risk?
[17:14] <ScottK> DktrKranz: Yes.
[17:15] <\sh> ScottK: that's my conclusion, too...and I don't want to "punish all upstreams wanting newer versions of their software" but "subjectiveness doesn't count as SRU" ;) (and yes..when I'm upstream and I want to push a much better working version of my software into distros, I would argue about it...)
[17:15] <DktrKranz> ScottK: since it has been requested for hardy too, I can test them for both hardy and gutsy and file a backport request
[17:16] <\sh> DktrKranz: I thought hardy is ok?
[17:16] <ScottK> DktrKranz: OK.  Let me know when you need a backports ack.
[17:16] <DktrKranz> \sh, it's ok for this, but bug 243163 brings in new issues
[17:18] <\sh> "There's apparently a new SRU process that allows you to take stable updates." hmm? did I miss something?
[17:18] <DktrKranz> IIRC, no
[17:20] <DktrKranz> IMO, there isn't a clear rule if a new upstream is suitable or not, it just depends how many changes it brings in and what kind of changes
[17:21] <\sh> since I used 4 aspirin today to get rid of my headache...I don't want another one, just because of one package...
[17:22] <DktrKranz> sounds reasonable :)
[17:23] <\sh> DktrKranz: well, we will have the same discussion somehow for leonov in the future 8->
[17:23] <DktrKranz> :)
[17:24] <DktrKranz> we already have one for flashplugin-nonfree
[17:24] <DktrKranz> but we can't do otherwise
[17:26] <\sh> :)
[17:29] <Ash-Fox> I swear, making LSB builds of anything is insanely difficult.
[17:38] <pochu> it would be really useful to have binNMUs in Ubuntu for transitions...
[17:42] <ScottK> Agreed.
[17:43] <ScottK> \sh: There are some packages for which it's been decided new point releases are OK, but the upstream is known reliable and is known to ONLY put bug fixes in the point release.
[17:43] <ScottK> \sh: It's not a free for all.  Postgresql is an example.
[17:44] <\sh> ScottK: ok
[17:44]  * \sh goes home now
[17:45] <ScottK> bliZZardz: Feel free to ask your question, just do it here.
[17:46] <bliZZardz> ScottK : that was a bug related Q - hence asked in #ubuntu-bugs
[17:46] <ScottK> Ah. I'm not in #ubuntu-bugs.
[17:47] <ScottK> Asking me there, won't get you much of an answer.
[17:47] <bliZZardz> w.r.t bug #229575 - this looks like a valid request. i am able to find this right from feisty(not sure abt versions before that :) ) - should this be taken up during packaging?
[17:48] <bliZZardz> am not sure whether this is an upstream request or not
[17:56] <pochu> bug 245594
[17:58] <highvoltage> how strict is man age formatting in ubuntu?
[17:58] <highvoltage> I've seen a few different layouts. is there a policy anywhere?
[17:59] <sistpoty> hi folks
[18:00] <highvoltage> hi sistpoty
[18:00] <sistpoty> hi highvoltage
[18:01] <pochu> devfil: around?
[18:01] <devfil> pochu: yes, I'm here
[18:01] <sistpoty> oh, nice... with today's kde-related upgrade, kvirc once again shows highlights from the tray icon :)
[18:06] <ScottK> bliZZardz: I'm sorry, I have gotten caught up in some stuff and don't have time to answer.
[18:06] <warp10> There is a packaging request on launchpad for bzr-gedit. I was wondering if such a software should be merged with gedit-plugins, or rather go in another package.
[18:06] <warp10> My concern is that merging it in gedit-plugins, would add a dep on bzr, that isn't interesting for normal, non-technical users. What's your opinion?
[18:11] <SWAT> directhex: sorry for the delay, I was in transit. It's freeorion, which is GPL
[18:12] <directhex> fnuh?
[18:12] <directhex> oh, right, sorry
[18:12] <directhex> i have a terrible memory, context is everything
[18:12] <SWAT> directhex: -3 hours, just scroll up ;)
[18:13] <directhex> SWAT, 3 hours is a lifetime!
[18:13] <SWAT> directhex: it depends on gigi, which is lgpl (I'll just package that too)
[18:14] <sistpoty> directhex: irc makes perceived time slower ;)
[18:15] <directhex> sistpoty, i'm generally slow
[18:15] <directhex> sistpoty, also easily confused when conversation carries on across physical locations
[18:15] <SWAT> time is relative, at least to some physicists
[18:16] <sistpoty> directhex: hah
[18:17] <SWAT> directhex: any thoughts on my situation? ;)
[18:19] <directhex> SWAT, seems packageable, but you'll be needing to split the package up to generate binary packages per-platform for the executable/libs and arch-independenct packages for the graphics/audio data (which doesn't need to vary per-platform)
[18:19] <directhex> SWAT, this can (and should) be done from a single source package, but it increases the complexity of the packaging work. sorry about that.
[18:20] <SWAT> directhex: no problem. The only issue is that I'll probably have to get it out of svn, so I'll build my own source package. I've built packages before, just for personal use. When the packages are done, what's the next step?
[18:21] <directhex> SWAT, adding a new package? REVU i think. not sure. i've only worked on existing packages
[18:24] <sistpoty> yep, revu please...
[18:24] <SWAT> directhex: I'll get to work on it, thanks.
[18:24] <sistpoty> !revu > SWAT
[18:24] <sistpoty> SWAT: and please also file a needs-packaging bug, if you haven't done so
[18:24] <SWAT> sistpoty: thanks, I was already on that page :)
[18:25] <sistpoty> heh
[18:25] <directhex> generally, try to get the package "technically" right before bothering people with revu - try to use revu for help with correcting "housekeeping" things like correct formatting of debian/control or whatever
[18:25] <directhex> making a package "work" repeatably is something you do via testing, not really via looking
[18:25] <SWAT> directhex: I know ;)
[18:26] <sistpoty> SWAT: oh, and in case you just now join revu-uploaders, I assume that persia would like to resync the keyring :P
[18:32] <SWAT> sistpoty, directhex, thanks for your time.
[18:32] <sistpoty> np
[18:49] <siretart> sistpoty: is there a role email adress for motu-release?
[18:49] <siretart> sistpoty: I need to contact motu-release as a team
[18:49] <sistpoty> siretart: no
[18:49] <sistpoty> siretart: I guess ubuntu-motu would be best
[18:49] <laga> your nicks are confusingly similar.
[18:50] <sistpoty> laga: that's because we studied at the same university, where login=si (student of informatik) + 2 from first name + 4 from last name
[18:52] <laga> ah. i just have 1 + first name + last name at my university. i guess i'm lucky
[18:54] <pochu> we have firstname.lastname
[18:54] <pochu> :)
[18:54] <RainCT> apt-cache really needs a -t option :(
[18:55] <siretart> sistpoty: can I phone you in about 20 mins?
[18:55] <sistpoty> siretart: sure
[18:55] <highvoltage> how long have debdiffs been around? is it relatively new?
[18:56] <directhex> i used to have initials + unique number signifying which number on the list you are with those initials (e.g. i had 5, a friend on the same course had 3), then the lst 2 year digits
[18:57] <directhex> nowadays it's a 4-digit code for the department i was in when i started, plus a 4 digit uid
[18:59] <sistpoty> highvoltage: afaict debdiffs were there already when I initially installed ubuntu (i.e. breezy)
[18:59] <siretart> highvoltage: check /usr/share/doc/devscripts/changelog.gz. It seems to date from april 99
[18:59] <RainCT> highvoltage: since 1999, it seems
[18:59] <RainCT> heh
[18:59] <sistpoty> *g*
[19:02] <highvoltage> well, I think it's the coolest thing ever and didn't know about it until just a few months ago.
[19:03] <sistpoty> hm... with LP's new ui, does anyone know where I can unsubscribe a team which I'm a member of (looking at bug #205735 atm)
[19:04] <highvoltage> can I attach debdiffs to bugs that apply to packages in main?
[19:04] <sistpoty> highvoltage: sure
[19:04] <highvoltage> sistpoty: excellent.
[19:04] <sistpoty> highvoltage: the procedure is identical, only the sponsors team is ubuntu-main-sponsors instead of ubuntu-universe-sponsors
[19:05] <highvoltage> sistpoty: aah
[19:05] <highvoltage> RainCT: I'm going to attempt to finish off a bug that you reported (bug 185171)
[19:06] <sistpoty> aha, I have to click on "subscribe yourself", to have the choice to unsubscribe the sponsors team
[19:07] <RainCT> highvoltage: great, feel free to ask if you've any question :)
[19:18] <highvoltage> RainCT: I happen to have one right now...
[19:18] <highvoltage> I see in the debian/rules file it says:
[19:18] <highvoltage> DEB_INSTALL_MANPAGES_libgnome2-common += debian/gnome-options.7
[19:18] <highvoltage> can I just add another line like that that ends with gnome-open.1 ?
[19:20] <RainCT> highvoltage: yeah
[19:20] <RainCT> but debian/gnome-open.1 rather
[19:21] <highvoltage> RainCT: ok
[19:21] <highvoltage> the old version was 2.23.3-0ubuntu1, so the new version should be 2.23.3-0ubuntu2, right?
[19:21] <RainCT> highvoltage: and gnome-open is in libgnome2-0
[19:21] <RainCT> right
[19:22] <highvoltage> eesh. ok. I just went with libgnome as the bug report suggested.
[19:23] <highvoltage> ah, but it seems right? libgnome-2.23.3
[19:24] <highvoltage> ah I see there's a libgnome2.0 package. back to the drawying board then :)
[19:24] <RainCT> highvoltage: yes, the libgnome source package creates many binary packages, one of which is libgnome2-0
[19:24] <highvoltage> RainCT: aah
[19:44] <highvoltage> may I gzip a debdiff before attaching it to a bug report?
[19:45] <geser> highvoltage: how big is the debdiff?
[19:45] <highvoltage> geser: 64KB uncompressed, 8KB compressed
[19:46] <highvoltage> I suppose that's small enough to include as-is
[19:46] <highvoltage> but I also don't want to bloat launchpad :)
[19:46] <geser> me too, and a step less for the sponsor :)
[19:46] <highvoltage> good point, uncompressed it is then
[19:46] <highvoltage> launchpad can handle it :)
[19:53] <highvoltage> so, if the debdiff is on the bug report, do I change the status to 'fix committed', or does that only happen when it actually gets merged with the ubuntu sources again?
[19:57] <highvoltage> ah, I can probably just change it to "In Progress". that would make sense, I think
[20:01] <highvoltage> why is the priority for the gnome-open manpage bug on wishlist?
[20:01] <highvoltage> isn't it policy to have a man-page for every executable?
[20:02] <laga> i thought that, too.
[20:02] <laga> AFAIK, many ubuntu tools don't have man pages.
[20:02] <laga> eg jockey
[20:05]  * highvoltage made a comment about that on the bug
[20:05] <highvoltage> maybe someone will answer :)
[20:06] <highvoltage> it's the same for bug 160414 as well
[20:06] <Iulian> highvoltage: You might want to have a look at https://wiki.ubuntu.com/Bugs/Status and https://wiki.ubuntu.com/Bugs/Importance
[20:06] <highvoltage> so maybe there is reasoning behind it
[20:06] <highvoltage> Iulian: thanks, will do so immediately
[20:08] <highvoltage> Iulian: thanks, that is very helpful. imho, a "low" priority would be more appropriate than "wishlist"
[20:10] <Iulian> highvoltage: Really, it doesn't make any difference if the priority of the bug is "wishlist" or "low"
[20:13] <Iulian> highvoltage: If you're working on that bug I can change that for you if you want but it doesn't make any difference.
[20:14] <highvoltage> Iulian: ok, no problem! no need to change them.
[20:15] <highvoltage> Iulian: I guess that it just "feels wrong" to label a policy violation as a wishlist item
[20:15] <highvoltage> but that's probably just me then,
[20:15] <highvoltage> .
[20:17] <Iulian> highvoltage: Well, some Ubuntu devs doesn't like binary packages without a manpage when sponsoring a new package.
[20:17] <Iulian> highvoltage: + lintian will complain if it doesn't have a man page.
[20:18] <ScottK> It's not just 'don't like' it's policy.
[20:19] <Iulian> ScottK: Yea indeed.
[20:19]  * ScottK will change it.
[20:20] <highvoltage> ScottK: thanks, and sorry to be such a pest about it :)
[20:21] <laga> ScottK: change what? change policy or priority?
[20:22] <ScottK> Changed the priority to Low from Whishlist since it represents a minor defect in the packaging.
[20:24] <RainCT> OT, can someone here vala? I'm wondering if it's worth to learn it
[20:27] <tbielawa> hey all
[20:27] <tbielawa> I got feedback on a REVU commit a bit back and I don't see where it applies. Can anyone help me resolve item 4:
[20:27] <tbielawa> http://revu.ubuntuwire.com/details.py?upid=2395
[20:28]  * sistpoty looks
[20:28] <emgent> heya
[20:29] <sebner> huhu emgent our prospetive motu :)
[20:30] <tbielawa> sistpoty, thanks
[20:30] <sistpoty> tbielawa: it doesn't apply for upload 2395 at least
[20:31] <tbielawa> sistpoty, I see it appears 2311. Thanks for clearing that up. I was confused
[20:31] <sistpoty> np
[20:31] <DktrKranz> sebner, are you crazy to "huhu" at yourself? :)
[20:31] <sebner> DktrKranz: ????? O_o
[20:32] <sistpoty> huhu sebner :P
[20:32] <tbielawa> sistpoty, I've resolved everything but item 6. I did a find on the base directory and there's a lot of .py files which are +x and have a shebang.
[20:32] <DktrKranz> sebner, I misread :D
[20:32] <tbielawa> this will hurt to resolve
[20:32] <sebner> sistpoty: yeah huh you too xD
[20:32] <sebner> DktrKranz: rofl xD
[20:33] <sistpoty> tbielawa: write a script to change these ;)
[20:34] <tbielawa> sistpoty, the find command is my friend.
[20:34] <sistpoty> heh
[20:34] <tbielawa> I suppose I'll just find out which are /supposed/ to have a shebang when things stop working then, huh?
[20:35] <sistpoty> tbielawa: maybe it might be a good idea to find out which scripts are meant to be executed directly?
[20:36] <tbielawa> sistpoty, there is only one which you would actually execute, that I know of
[20:36] <sistpoty> tbielawa: that's a good start ;)
[20:37] <tbielawa> sistpoty, this task doesn't seem quite as insurmountable any longer. thanks
[20:37] <sistpoty> you're welcome ;)
[20:45] <sebner> sistpoty: do you know if a archive admin is around? They stole my syncs. ehm I mean my name isn't written there but auto-sync O_o
[20:46] <sistpoty> sebner: blame pitti, as he accidantly ran autosync recently ;)
[20:46] <crimsun> if only stealing autosync naming were the worst of our troubles.
[20:46] <sebner> sistpoty: again? I mean, I filed syncs. They go ACK and an archive admin set it to Fix Released
[20:47] <sebner> crimsun: xD, hey thanks for flash 10 beta2 :D
[20:47] <sistpoty> sebner: not too sure, he told s.th. about "friday habits" earlier on on #ubuntu-devel
[20:47] <sebner> lol
[20:47] <sebner> kay
[20:48] <sistpoty> sebner: however from your +packages page, do you really need more before you go for motu?
[20:48] <sistpoty> ;)
[20:48] <crimsun> sebner: thank RAOF not me.
[20:49] <sebner> sistpoty: well there are only shown the last 50 ones but I have a deal with Luca to have 250 uploads before applying. Now I don't now how many I have. officially 200 uploads but they should be ~203
[20:49] <sebner> crimsun: why? -- Daniel T Chen <crimsun@ubuntu.com>   Wed, 02 Jul 2008 23:29:04 -0400
[20:50] <sistpoty> sebner: apply for motu! do it! that's an advice! *g*
[20:50] <crimsun> sebner: because he's responsible for signing the source package and uploading.
[20:50] <sebner> sistpoty: lol, no. first packing things from scratch. first easy package will be tomorrow on revu =) besides I'll think about me and my ubuntu future in my ireland holidays
[20:51] <sebner> crimsun: ah nvm. so *also* thanks to you ;) finally I can use my keyboard again and play flash games xD
[20:51] <sistpoty> sebner: oh, so you're trying to escape to ireland from motu? *g*
[20:52] <sebner> sistpoty: maybe ^^ no to be honest I'm not happy at all with ubuntu rules etc
[20:52] <sistpoty> sebner: with which rules are you not happy?
[20:52] <sebner> sistpoty: nvm. I'll do a discussion with persia later
[20:52] <sistpoty> (feel free to query me, if you don't want to discuss this in public
[20:52] <sistpoty> +)
[20:58]  * RainCT is reading the log..
[20:58] <RainCT> about the gnome-open manpage bug's importance, for this package I agree that it should be Low
[20:58] <geser> \o/ some quiet time for u-u-s soon :)
[20:59] <sebner> geser: O_o
[20:59] <RainCT> but if it was in universe I wouldn't be that sure, as the wiki says about importance Low «A bug that has a moderate impact on a non-core application »
[21:00] <emgent> hello RainCT sebner geser sistpoty ecc.. ecc..
[21:00] <geser> Hi emgent
[21:00] <sistpoty> hi emgent:
[21:00] <sistpoty> -:
[21:02] <RainCT> hey emgent
[21:03] <null_vector> ugh, installing libc failed during upgrade to intrepid
[21:03] <RainCT> geser: hehe seems like that's a workaround for the "can't stop sebner" bug on staging.launchpad.net (which has already been deleted :()
[21:03] <sebner> RainCT: xD
[21:04] <geser> RainCT: there is still the screenshot :)
[21:05] <RainCT> geser: yeah :)
[21:33] <tbielawa> it seems like the kernel and virtualbox are always out of sync recently
[21:37] <tbielawa> non-ose ftw I guess
[21:38] <laga> dkms ftw
[21:39] <tbielawa> kvm ftw
[21:40] <tbielawa> though dkms does look like something I should look at in greater detail later
[22:18]  * sistpoty must go to bed now.. gn8 everyone
[22:20] <sebner> gn8 folks
[22:25] <emgent> bye sebner
[22:28] <nxvl> emgent: what are you doing on IRC, you should be drinking
[22:28] <emgent> nxvl: lol
[22:28] <emgent> nxvl: why ?
[22:29] <Nafallo> hmm
[22:29] <Nafallo> I did it the other way around :-)
[22:31] <nxvl> emgent: because it's friday, and almost midnight at your tz
[22:31] <emgent> nxvl: i know, but tomorrow i should work
[22:32] <nxvl> ember: oh! ok, there you have a problem, i didn't say nothing in that case
[22:32] <nxvl> :P
[22:32] <emgent> hehehe :)
[22:33] <DktrKranz> nxvl, almost midnight here too, but there's nothing at all... so I come back home :(
[22:34] <emgent> hehe
[22:34] <nxvl> DktrKranz: where in the world are you?
[22:34] <DktrKranz> nxvl, italy
[22:35] <nxvl> same as emgent
[22:35] <nxvl> that's cool
[22:35] <emgent> no, it`snt..
[22:35] <nxvl> in peru there is always something to do
[22:35] <emgent> nxvl: can i send Berlusconi & CO in Peru ? :)
[22:36] <nxvl> to the point that sometime i don't do anything cause i'm sick of drinking
[22:36] <DktrKranz> ember, no politics :)
[22:36] <DktrKranz> nxvl, come tomorrow, you'll have to drink a lot
[22:36] <emgent> DktrKranz: heheh ok
[22:37] <nxvl> emgent: plese don't, we have to much with our politics
[22:37] <DktrKranz> oh, I mean emgent, not ember (sorry for bogus ping)
[22:39] <norsetto> I'd propose bug 245679 as BOTD
[22:40] <nxvl> BOTD?
[22:40] <norsetto> nxvl: Bug Of The Day, what else!?
[22:41] <nxvl> :D
[22:41] <nxvl> Build Over Trunk Data?
[22:41] <nxvl> :P
[22:41] <emgent> Uploaded by nhandler
[22:42] <nxvl> to much text to read for a classroom
[22:42] <nxvl> i after my class
[22:43] <nxvl> s/i/i'll/g
[23:30] <beDrung> DktrKranz: Is there someting I have to do for bug #221205? I am not a MOTU, so I need someone who sponsors me.
[23:31] <DktrKranz> beDrung, I can upload it, but need to boot a hardy box to test it
[23:31] <DktrKranz> I subscribe to it, so I keep track
[23:33] <beDrung> normally setting a bug to fix released means that I need a sponsor. but this does not apply for sru?
[23:36] <DktrKranz> fix released means fix is already in the archives
[23:42] <beDrung> DktrKranz: ok
[23:53] <beDrung> Does someone get a point of bug #245701