[00:48] ScottK: awesome! thanks very much :) [00:49] Bah, can I use dh_installinit with an upstream provided init file? All the docs I can see need one in debian/ [00:56] hi vorian good luke :) [00:56] thanks, same to you :) [00:56] hehe thanks :) [00:58] RAOF: thanks [01:00] TheMuso, \sh: bug 239719 is waiting for you when you have time to look at it (with minimal debdiff now) :) [01:00] Launchpad bug 239719 in youtranslate "[SRU] YouTranslate! in Gutsy and Hardy doesn't work." [Medium,New] https://launchpad.net/bugs/239719 [01:00] crimsun: No problem. [01:11] RainCT: Ok lookign now, since I'm in an SRU mode. [01:12] RainCT: Is this in intrepid? [01:15] 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] Having some changes in the .diff.gz and some in a patch file doesn't make sense. [01:16] RainCT: ^^ [01:19] TheMuso: they are in a patch [01:19] RainCT: Um doesn't appear that way to me. [01:19] TheMuso: 02_fix_ftbfs.dpatch [01:19] jono, ping [01:21] TheMuso: where are you looking? [01:21] TheMuso: (and yes, those changes are in intrepid together with a new upstream version and many other packaging improvements) [01:21] RainCT: Sorry, I misread the patch. [01:21] cody-somerville: isn't it 1am in London? [01:22] RainCT: ACKing. [01:22] TheMuso: great, thanks :) [01:22] LaserJock, aye [01:22] RainCT: One change, hardy-proposed and not hardy [01:24] TheMuso: argh, right [01:24] I had to do something wrong :P [01:24] RainCT: heh [01:24] has anybody been thinking about building an Ubuntu PTS? [01:26] LaserJock: what are you missing in LP? [01:26] quit a bit of stuff [01:28] hello people :) [01:32] RainCT: sorry, was afk [01:32] np [01:33] things that come to mind are stuff from qa.ubuntuwire.com (unmet deps, FTBFS, NBS, etc.) [01:33] right now what I'd like is a package whiteboard too [01:33] so we can leave "notes" for each other [01:34] LP also doesn't track upstream versions [01:34] it would be good to have the Ubuntu version, Debian Version, and Upstream Version easily viewable [01:35] LaserJock: Right. So basically an overview page for all the QA stuff affecting a single package [01:35] pretty much yeah [01:35] there would be a bit more than just QA stuff [01:35] sounds useful [01:35] but a lot of it would be yeah [01:39] 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] wgrant: I talked with ogasawara today and she seemed to want to work on something like that [01:40] and I've wanted to for a long time [01:41] LP really should do it. [01:41] some of it [01:41] But there's no chance of that until it's Freed. [01:41] even then [01:41] a lot of it is fairly specific to Ubuntu [01:42] I would like to see a package whiteboard in LP though [01:42] well, good night guys [01:42] night [01:43] 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] wgrant: perhaps [01:44] like today I could have used it [01:44] Debian is currently trying to figure out a library issue [01:45] but in the mean time I don't want people merging or trying to "fix" dependent packages [01:45] it feels a tad weird to file a bug to have work *not* done :-) [01:47] I've seen it done a number of times. [01:47] "Don't merge X from Debian unstable" [01:47] it also implies that people actually look for those books [01:47] Bugs? [01:48] bah [01:48] distracted, sorry [01:48] I always do before I upload - I hope everybody else does. [01:48] I've only clobber one contributor's merge before. [01:48] Certainly for merges. [01:48] well, this isn't a merge [01:48] it'd be changing build deps [01:49] Even so, people should be checking for other bugs they can fix in that upload. [01:49] *should* ... [01:49] Right. [01:49] well, if reasonably, yes. [01:50] I didn't bother with several, e.g., flashplugin-nonfree. [01:50] "closes foo, bar, baz, a, b, c, ..." is a bit tedious. [01:52] Oh, thinking of which, I haven't done anything except upload to intrepid; it needs uploading to hardy-proposed, etc, right? [01:52] Where 'it' is flashplugin-nonfree, obviously. [01:53] RAOF: I'd hold off on that. [01:53] Flash 10? [01:53] Yay! Less work. [01:53] there's no confirmation that beta 2 resolves any of the security issues currently present in hardy's. [01:54] Beta2 does still manage to consume a core, though. [01:54] yes, very effective DoS. [01:55] So multicore is a good security measure! [01:55] Less effective than gnash, which has a tendency to consume all memory. [02:19] ember: ping about wordpress [02:20] emgent ? [02:20] err.. i didn't saw sispoty comment [02:20] i'm gonna have a look at it emgent [02:20] thanks [02:21] ok nice, Thanks to you [02:27] argh stupid comment on dad main -.- [02:27] "school girls xxx" [02:28] lol [02:29] i go to clean it. [02:29] 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] :) [02:31] \o\ /o> /o/ [02:31] nxvl: what is it ? [02:32] * nxvl dancing [02:32] but it look more like steps :S [02:32] looks* [02:32] lol, you are crazy :) [02:33] or someone with a drunken xml fetish :) [02:33] hahaha [02:33] heh [02:33] emgent: nop, i'm boried, i'm in classes [02:37] got dammit, my class already ended and my girlfriend ends in an hour [02:48] i don't understand why vimtutor isn't working for me [02:51] 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? === keylocker is now known as leleobhz [03:04] nxvl: Your girlfriend ends in an hour? Man, what're you doing on IRC!? :) [03:25] RAOF: lol [03:25] RAOF: classes [03:26] she is already here!! [03:26] im gone [03:26] Yay! [03:26] read you! [03:30] Heya gang [03:41] Heya [03:41] Hi cody-somerville [03:47] heya bddebian cody-somerville [03:49] lo [03:56] Hi emgent [04:15] * mneptok staples cody-somerville to his thigh [04:15] ack! [04:16] happy canada day! (late) [04:17] have a cold O'Keefe's served in a pewter toque! [07:06] <\sh> bug #239719 acked ready for -proposed [07:06] Launchpad bug 239719 in youtranslate "[SRU] YouTranslate! in Gutsy and Hardy doesn't work." [Medium,In progress] https://launchpad.net/bugs/239719 [07:20] good morning [07:24] Morning. [07:24] hi AstralJava [07:25] Hello dholbach! :) [07:33] dholbach: you have make a lot of videos the same day, but they are being released periodically, don't you? [07:33] over two days, but yeah [07:33] hi DktrKranz [07:33] so, they are more comming? [07:33] hi dholbach [07:34] I think one more [07:34] for now [07:37] :D [07:37] they are really cool btw [07:40] thanks a lot [07:40] i always use them on my packaging jams [07:45] they help me to give the participants a quick overview about the process [07:45] and then start to do the same process step by step with them [07:45] :D [07:45] I'm very glad they're useful [07:45] we should do some more of them as a team: http://wiki.ubuntu.com/MOTU/Videos [07:46] i will be glad [07:46] cool [07:46] 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] luckily https://wiki.ubuntu.com/ScreencastTeam/RecordingScreencasts has some information about how to do that [07:47] yeah, i can find a camera [07:47] or [07:47] as you say just do screencast [07:47] with added audio it should be quite good [07:47] dholbach: how do you find the idea of translating them? [07:47] yeah, of course [07:48] nxvl: I'm all for it! [07:48] translating can be difficult [07:48] sharing the love [07:48] with translating i mean record same process in spanish, not just edit the audio [07:48] you have to basically redo them 100% [07:48] you want to use the screen localised too in that case [07:49] or if you want to do it the easy way, you could just add subtitles [07:49] well [07:49] to read subtitles plus read the commands [07:49] is quite hard [07:50] dholbach: or you were thinking on editing the audio or writing subtitles? [07:50] no, redoing them [07:50] ok [07:50] yes [07:50] i find it better [07:50] i will try to find some equipment this weekend [07:51] * dholbach hugs nxvl [07:51] awesome awesome awesome [07:51] * nxvl hugs dholbach back [07:51] now [07:51] i need to sleep [07:51] sleep tight :) [07:51] i need to fight with php code on the morning [07:51] btw [07:51] i hate php [07:51] good idea (even I just got up) :D [07:51] txwikinger: 2 am here [07:52] well.. I got up 5am this morning [07:52] dholbach: we should write some documentation on "translating the videos" or "doing videos" to have kind of a standard [07:52] nxvl: just add it to https://wiki.ubuntu.com/MOTU/Videos [07:53] dholbach: but we can coordinate it by e-mail [07:53] sure [07:53] dholbach: yes, i mean, for more people to do them on their languages [07:53] right [07:53] i will send you and jono an e-mail this weekend with it [07:53] alright [07:53] thanks Nicolas [07:53] have a good day! [07:54] gracias [07:54] dholbach: there is nothing to thank :D [07:54] just a lot of love to give to new contributors [07:54] exactly :) [07:54] now i'm gone [07:59] G'morning [08:55] 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] slytherin: You want it processed from the source NEW queue? [08:58] 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] 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] 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] slytherin: Batik is a NEW package? I thought we had it in the repos. [09:04] 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] 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] slytherin: Yes, but you don't need two people: you can just put it in the sponsors queue as normal. [09:05] persia: but then I will also have to upload the repackages source right? [09:05] /repackages/repackaged [09:06] 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] 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] persia: Do you have any example repackaging encoded in get-orig-source? Please note that I also need to do 'svn export ' in this case. [09:11] slytherin: adblock-plus, for example, has a get-orig-source where it does a "bzr export" [09:11] RainCT: Cool. Thanks. I will take a look. === dholbach_ is now known as dholbach [09:45] Iulian: giver has no dependencies [09:47] Iulian: bug 245431 [09:47] Launchpad bug 245431 in giver "no dependencies" [Undecided,New] https://launchpad.net/bugs/245431 [10:01] Riddell: Yes, I'm preparing an upload to Debian with the fix. [10:02] Riddell: It should be in Debian in a couple of days and then we can sync. [10:03] Riddell: I can also make an upload to Ubuntu right now with some fixes but I think we should wait for Debian. [10:05] Iulian: cool, thanks [10:07] Riddell: So, what do you prefer? Wait for Debian or prepare an upload to Ubuntu today? [10:08] waiting is fine with me [10:09] Riddell: Okay [10:15] huhu jono [10:16] dholbach: thanks for ACKing my syncs and sry for the inconvenience [10:16] DktrKranz: now the 200 are full ;) [10:16] huhu sistpoty|work [10:16] hi folks [10:16] hi sebner [10:17] morning afflux ;) [10:17] hi sebner :) [10:20] sebner: the more you do the more I'll beat you when I catch you :D [10:21] ScottK: Are you this SpecialK that I see uploading lots of backports? [10:58] Laney: giving up on btx? [10:58] norsetto: Yes, I found some problems with the upstream code that make it too much work to include. [10:59] And that fact that the -config UI must run as root will surely make that one more difficult to accept too. [11:00] I think it needs a few more releases to mature before it'll be ready [11:02] 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] norsetto: Righto, just didn't want to clutter up the list [11:03] norsetto: Thanks for your review too, it helped me come to this conclusion :) [11:03] 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] Laney: glad I could help [11:10] from df on spooky (revu's host): /dev/md0 70568272 30367488 36644336 46% /srv [11:10] so not a problem in regards to disk space atm :) [11:12] sistpoty|work: I was more thinking visual screen space, or if someone decided to review it ;) [11:47] Laney: well, you can archive it, then it won't show up on the front page [11:48] uhm.. that was a fast answer.. :P [11:48] heh [11:48] 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] ok, done [11:49] sistpoty|work: btw, REVU converts URLs into links now :) [11:49] (in comments) [11:49] Thanks [11:49] cool RainCT :) [11:57] siretart: Is it OK to do the ffmpeg-free rebuilds? [12:05] Hi [12:06] I am trying to use pbuilder to verify correct build of a package [12:06] 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] Laibsch: Are you encountering an issue? [12:06] of course I am ;-) [12:07] Why does pbuilder want to call mknod? [12:08] [12:08] 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] ? [12:08] Festor, 0 [12:08] ok, thanks [12:09] Festor, the X in XubuntuY refers to the debian revision - 0 for not-in-debian [12:09] then 1.2-0? [12:10] no [12:10] ehh [12:10] 1.2-0ubuntu1 [12:10] AFAIK [12:10] 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] but ubuntu1 is the debian revision, no? [12:10] and my package does not exist in debian [12:10] persia: One is supposed to build as root? [12:10] I find that hard to believe [12:11] How can I be sure not to f*ck up my system [12:11] Festor, it enables debian to take the package [12:11] ok [12:11] Festor: 0ubuntu -> not in debian (0), version 1 in ubuntu (ubuntu1) [12:11] Festor: 0ubuntu1 -> not in debian (0), version 1 in ubuntu (ubuntu1) [12:11] Festor, 0ubuntu1 means "this is the first ubuntu-specific version of a package with a debian revision of 0 (not at all)" [12:11] 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] 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] then 1.2-0ubuntu0? or 1.2-0ubuntu [12:12] Festor, and since syncs are better than merges, you want the first debian version to supercede the first ubuntu version [12:12] (13:10:10) Laibsch: 1.2-0ubuntu1 [12:12] Laibsch: In that case, you need to trust pbuilder to behave. [12:13] Festor: you said it yourself [12:13] * persia only has ~20GB under LVM, not everything [12:13] sorry [12:13] Festor, your package is debian revision 0 (non existent), ubuntu revision 1 thereof (first version to exist) [12:13] Festor, so 0ubuntu1. see? [12:13] ok, ok, thanks for all [12:14] This package is a amsn plugin === Zic is now known as Zic`Angine === Zic`Angine is now known as Zic [12:15] If I want to send to Intrepid should I put a bug in amsn? [12:16] Forget, I am reading the wiki ubuntu [12:22] is there a way to get dh_pysupport to also create optimized *.pyo files rather than just *.pyc? [12:23] jcfp: It would require changes to python-support, as the compilation happens at install-time. [12:24] persia: so there's not some easy switch to tell it to just do that [12:24] jcfp: Nope. [12:24] bummer. guess I'll have to use postinstall/prerm scripts then [12:24] 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] jcfp: You really don't want to do that. [12:25] huh [12:25] persia: any better way? [12:25] I thought python-support did pyo files [12:25] lifeless: only creates pyc here? [12:25] jcfp: Let's look at this differently: why do you need optimised compilation? [12:26] lifeless: There may be such an option, but it's not package-specific. [12:26] persia: upstream suggested doing so may give better performance? [12:26] Laney: sorry? [12:27] siretart: I saw you requested the deletion of ffmpeg, was just wondering if it was OK to request rebuilds of the NBS [12:27] interesting, no pyo's [12:27] that will suck when bzr starts running with -O by default [12:27] 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] 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] persia: I think you are missing some context :) [12:28] btw, there is /etc/python/debian_config but changes there dont seem to have any effect on dh_pysupport [12:29] persia: bzr is looking at making 'bzr' run with python -O rather than plain python [12:29] persia: this will cause .pyc files to not be used [12:29] persia: and that matters because users cannot write .pyo files to /usr/lib, so every invocation will have to byte compile [12:29] persia: -> slow [12:30] lifeless: similar stuff here, upstream by default uses -OO in the program [12:30] Laney: oh yes, please do! [12:30] siretart: Excellent, will do! [12:30] jcfp: unless they have significant memory use, or compiled pyc file size, it won't make much differnece [12:30] lifeless: Ah. You've already investigated it :) [12:31] persia: well, more than I know some parts of pythons internals :) [12:31] lifeless: investigating in 30 seconds from memory counts :p [12:31] Laney: I do expect some build failures. please file bugs with patches and tell me about them. thanks! [12:32] 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] persia: it won't break/unbreak things - because python -O will behave the same anyhow [12:33] just whether it has to JIT compile it [12:34] lifeless: But isn't JIT of .py when .pyc is available likely to not be much faster than using .pyc directly? [12:34] persia: python -O disables .pyc, thats the point. [12:34] 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] persia: if .pyc is available it is a big win over JIT compiling the .py [12:35] jcfp: yes [12:35] By policy, .pyc ought be available for any .py in any module on an Ubuntu system. [12:35] 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] jcfp: for instance: [12:36] strace python -O -c 'import bzrlib' [12:36] ... [12:36] read(5, "\"\"\"distutils.errors\n\nProvides ex"..., 4096) = 3636 [12:36] read(5, "", 4096) = 0 [12:36] unlink("/usr/lib/python2.5/distutils/errors.pyo") = -1 ENOENT (No such file or directory) [12:36] open("/usr/lib/python2.5/distutils/errors.pyo", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0666) = -1 EACCES (Permission denied) [12:37] python is really quite unfriendly to system wide installs [12:37] ayay ;) [12:37] 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] If I want to send to Intrepid my amsn plugin package should I put a bug in amsn? [12:38] The cheeseshop provides eggs? I thought python was supposed to be intuitive. [12:39] persia: cheeseshop often has setuptools based installer links [12:40] lifeless: Yes. That was intended as humor. Perhaps I oughtn't try to send you emotional content over IRC... [12:41] persia: irony and sarcasm need hints [12:42] ..orz [12:42] Festor: needs-packaging bugs are usually filed against ubuntu [12:43] Laibsch, this is not a "needs-packaging" [12:43] I made the package [12:43] I have diff.gz and orig.tar files [12:43] ??? [12:43] Is it already in the Ubuntu archives? [12:43] no [12:43] Is a new package [12:43] a plugin for amsn [12:43] Then you'll want to follow the REVU process [12:43] !revu [12:43] REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU [12:44] 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] ok [12:44] dholbach: ping [12:45] persia, lifeless: thanks for your input, made me a bit wiser again [12:47] slomo: thanks for the update :) [12:49] porthose: any success with bzr? [12:50] norsetto: havn't tried yet today give me a sec and I will try [12:51] norsetto: still get the same error. [12:51] porthose: have you seen my email? [12:52] yes [12:52] Rebuild requests which affect a few packages: One bug or one bug per package? [12:53] 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] 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] Laney: OK. Are you sure you need a bug? Will they appear in NBS? [12:54] persia: They already are [12:54] Ah, you're providing the debdiffs for the rebuilds? [12:55] persia: Yeah, I have no other way of getting things done ;) [12:55] 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] what are you NBS'ing? [12:55] It's ffmpeg->ffmpeg-free [12:56] 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] Laney: btw, we renamed it again from ffmpeg-free to ffmpeg-debian, but that package is currently sitting in debian NEW [12:57] Anyone have any suggestions for how Laney ought submit the diffs? [12:57] Laney: Based on the last comment: please wait :) [12:57]