[00:04] <cody-somerville> Laibsch, data management
[00:05] <cody-somerville> Laibsch, you'll want to look here for the .desktop file: http://standards.freedesktop.org/menu-spec/latest/apa.html
[00:06] <Laibsch> I guess data management is indeed the closest
[00:06] <Laibsch> although it does not feel quite right
[00:07] <Laibsch> from a pure user perspective
[00:09] <Laibsch> cody-somerville: Same problem for the .desktop file
[00:09] <Laibsch> utility?
[00:09] <Laibsch> that is awfully generic and there are already a ton of programs in there
[00:10] <Laibsch> but I guess closest match
[00:10] <cody-somerville> :/
[00:15]  * NCommander works on setting up his wiki page
[00:16] <norsetto> good night all
[00:19] <NCommander> cody-somerville, https://wiki.ubuntu.com/MichaelCasadevall, any coments?
[00:22] <Majost> So it seem that update  the update-maintainer doesn't actually generate the lines in the changes file for "Original-Maintainer" -- it does however change the Maintainer information in the control files.
[00:23] <Majost> What I am looking for is the script which dumps the line into the .changes file based on the Original-Maintainer line in the control files
[00:24] <RAOF> Majost: Which takes the source package and generates the .diff, .dsc, and .changes files?
[00:24] <Majost> correct.
[00:25] <RAOF> dpkg-genchanges is likely to be your winner.
[00:25] <Majost> yeah, I was just about to say that I couldn't find anything related to the "Original-Maintainer" in there
[00:25] <Majost> heh
[00:26] <RAOF> That'd probably be because O-M isn't an official control variable; the XSBC means eXperimental, appears in Source package, Binary package, and Changes file.
[00:26] <NCommander> RAOF, I'm suprised there ain't an ubuntu specific patch for killing that warning
[00:28] <RAOF> Yeah, perhaps.  I think we're just innured to the warning by now.  Also, unnecesary dpkg divergence seems a Bad Thing(tm).
[00:28] <Majost> The problem I am running into is there is a null space being inserted in between the last file checksum and the tags at the end of the changes file when a "Original-Maintainer" flag is set
[00:28] <Majost> which should be easy to fix -- I just need to find what creates the thing. heh
[00:29] <RAOF> And that space is breaking the changes file?
[00:30] <RAOF> That sounds like a bug in dpkg-genchanges, if the source package has been correctly built.
[00:31] <Majost> Well... its breaking my repo manager
[00:31] <Majost> heh
[00:31] <Majost> I will poke at dpkg-genchanges some more then.
[00:45] <warsocket>  k question, lets say ive made a program that would do nice in the ubuntu repository, what should i doe or who should i contact to get it there?
[00:52] <warsocket>  k question, lets say ive made a program that would do nice in the ubuntu repository, what should i doe or who should i contact to get it there
[00:53] <jmarsden> warsocket: Don't repeat yourself :-)  Have you read the Packaging Guide https://wiki.ubuntu.com/PackagingGuide/Complete ?
[00:55] <jmarsden> I think https://wiki.ubuntu.com/MOTU/Contributing#head-f4c6048b1531f4e4fe48f096350ea435d40ed9f5 would also be very useful to you as a starting point?
[00:59] <vorian> warsocket: you can file a [needs-packaging] bug on launchpad if you don't want to package it
[01:01] <cody-somerville> jmarsden, whats the bug number again?
[01:03] <jmarsden> LP: #91237
[01:05] <jmarsden> Hmm, yesterday when I typed bug numbers in the channel ubottu responded with a one line summary of the bug, but today he is silent?
[01:06] <cody-somerville> bug #91237
[01:07] <jmarsden> Hmm, it went to undecided and invalid?  It was High and Confirmed yesterday, I think.
[01:09] <jmarsden> Oh, it is Triaged / High against Ubuntu, but undecided/invalid against meta-kde?  What is the meta-kde part realy telling me?
[01:10] <cody-somerville> jmarsden, its tell you someone screwed up
[01:11] <jmarsden> As long as someone != jmarsden, that's fine :-)
[01:11] <cody-somerville> :)
[01:25] <jmarsden> What is the "right" way to deal with old config.guess and config.sub files in the orig.tar.gz ?  Just nuke them with symlinks to the ones in /usr/share/misc in the rules file ??
[01:42] <NCommander> jmarsden, just replace them in a build rule, and remove them in a clean rule; dpkg-source will not note a file has been removed
[01:43] <jmarsden> NCommander: OK, thanks.
[01:47] <NCommander> anyone got a PPA full of intrepid packages? I need to test something
[01:48] <NCommander> nice netsplit
[01:50] <RAOF> NCommander: I've got some Intrepid pakcages in the nouveau ppa?
[01:50] <NCommander> RAOF, thanks, I'm stress testing the parsing code to see how big a PPA it can handle before things begin to crawl
[01:51] <RAOF> Ah.  My PPA isn't very big; just libdrm & xserver-xorg-video-nouveua
[01:51] <NCommander> RAOF, I don't see and dist intrepid packages in the nouveau PPA
[01:52] <NCommander> actually
[01:52] <NCommander> there is no nouveau ppa
[01:52] <RAOF> Sorry, I'm talking about this https://edge.launchpad.net/~raof/+archive
[01:54] <NCommander> RAOF, ah ;-)
[01:54]  * NCommander thinks is really cool that he can now parse debian source files :-)
[02:14] <rootvzla> hi n.n
[02:20] <cody-somerville> jmarsden, so, is that a regression in Hardy?
[02:21] <jmarsden> cody-somerville: I'm not sure, I've not run iriverter in anything else myself.
[02:21] <cody-somerville> jmarsden, because it is now fixed in Intrepid and I'm wondering if you should do an SRU for it.
[02:23] <jmarsden> cody-somerville: Interesting question... do you have an older Ubuntu box around to try it on??
[02:23] <cody-somerville> No but that isn't inherently required
[02:23] <jmarsden> cody-somerville: OK, how else can we test to make sure?
[02:24] <cody-somerville> jmarsden, Maybe you misunderstand. What make sure of what?
[02:24] <jmarsden> cody-somerville: Make sure iriverter worked in an earlier version of Ubuntu but fails in Hardy
[02:25] <jmarsden> Isn't that the definition of a regression?
[02:31] <cody-somerville> jmarsden, yup
[02:31] <cody-somerville> jmarsden, but it isn't necessary for it to be a regression to get an SRU
[02:31] <cody-somerville> jmarsden, it would just motivate me if it were
[02:31] <jmarsden> Ah, OK.  What does it take to get an SRU designation?
[02:32] <cody-somerville> jmarsden, I'd approve it on the basis that it is a simple patch/fix and it the application doesn't launch at all right now.
[02:32] <jmarsden> cody-somerville: Well, it does until you install Sun Java :-)
[02:33] <NCommander> That sounds SRU worthy
[02:33]  * NCommander kicks phpPGAdmin
[02:33] <emgent> hey cody
[02:33] <cody-somerville> heya emgent
[02:34] <rootvzla> hey cody-somerville
[02:35] <rootvzla> hey jmarsden
[02:35] <cody-somerville> heya
[02:35] <jmarsden> rootvzla: Greetings
[02:44] <dldc> hi
[02:44] <dldc> some suggest to make merges by hand?
[02:45] <dldc> i have debian orig.tar.gz .dsc and .diff.gz and i have too .dsc and diff.gz
[02:45] <dldc> how to merge it ?
[02:45] <rootvzla> greetings jmarsden , cody-somerville a question 1)¿there is some person that explain me or can explain me on as one it is able comensar to do motu or that is needed to be able to be motu? 2)and if there is some person that can help me to be motu or some person it can help me en empaquetamiento or it helps of algun motu especially?
[02:45] <dldc> i dont like grab_merge.sh script
[02:45] <nxvl> using grab-merge script and MoM
[02:46] <cody-somerville> !gettingstarted
[02:46] <dldc> nxvl no, i'd like learn to merge by hends
[02:46] <cody-somerville> !getstarted
[02:46] <cody-somerville> hmrph
[02:46] <dldc> !motu
[02:46] <jmarsden> rootvzla: See https://wiki.ubuntu.com/MOTU/Contributing
[02:46] <nxvl> dldc: then check at MoM's code
[02:46] <dldc> thanks cody-somerville
[02:46] <nxvl> dldc: and then use it
[02:46] <nxvl> :D
[02:47] <dldc> nxvl no doc?
[02:47] <nxvl> no
[02:47] <cody-somerville> !gettingstarted is <reply> A great place to start your MOTU adventure is https://wiki.ubuntu.com/MOTU/GettingStarted
[02:47] <dldc> sucks..
[02:47] <nxvl> why would we write a doc if we already wrote a tool that makes it
[02:47] <nxvl> it makes no sense
[02:48] <dldc> i like learn how to merge by hands
[02:48] <nxvl> then read the code
[02:48] <cody-somerville> dldc, to merge by hand, you simple take the latest debian version and make all the applicable changes that are made to the current ubuntu version
[02:48] <cody-somerville> dldc, so that there are no regressions
[02:49] <dldc> cody-somerville but WHY dpkg-source -x *.dsc dont work ?
[02:50] <cody-somerville> dldc, it does work.
[02:50] <cody-somerville> dldc, It will extra the source
[02:50] <cody-somerville> dldc, but if you do it one after another and the upstream version is the same, it'll overwrite
[02:50] <dldc> ohhhhhh good!
[02:51] <cody-somerville> :)
[03:00] <rootvzla> thx cody-somerville
[03:01] <cody-somerville> rootvzla, np
[03:01] <NCommander> ScottK, ping
[04:38] <coppro> ****!
[04:38] <coppro> what's the fastest way to download a package from revu?
[04:39] <jscinoz> dget the dsc?
[04:39] <coppro> thanks
[04:39] <jscinoz> `dget DSC-url`
[04:39] <coppro> I accidentally nuked my entire package tree with an incorrect usage of sed
[04:39] <coppro> I always do sed <file >file, and forget that the output truncates the file before sed gets to it
[04:40] <coppro> :(
[04:43] <coppro> how do I generate the source tree from those (I'm am new at this)?
[04:52] <jdong> coppro: btw, see sponge in moreutils regarding redirection truncation
[04:52] <jdong> coppro: you want to use dpkg-source -x on the .dsc
[04:52] <coppro> thanks
[04:53] <coppro> thanks, sponge is _exactly_ what I need
[04:53] <coppro> btw, are you a MOTU by any chance?
[04:55] <coppro> :( I lost a lot of work... most of it was problem-solving, fortunately
[05:02] <NCommander> It could be worse coppro
[05:02] <NCommander> I've done that working on Bazaar brances
[05:02] <coppro> I need to re-write the code for generating the docs & python packages though :(
[05:03] <NCommander> coppro, try rewriting a 1,000 line file retriever in raw C :-P
[05:04] <coppro> owch
[05:04] <coppro> bash should totally give an error if you <file >file
[05:04] <NCommander> coppro, set noclobber
[05:05] <coppro> does that stop that only, or all > clobbers?
[05:05] <coppro> wow, I'm on an absolute roll today, I just ran rm * in my home directory ><
[05:05] <StevenK> Woot
[05:05] <StevenK> Yay for backups
[05:06] <coppro> unfortunately, due to a number of unfortunate circumstances, I have no backups right now!
[05:06] <coppro> fortunately, I don't keep anything of value in ~, but in subdirectories
[05:07] <RAOF> Grrr, stupid maple truncating it's files before saving, then freezing part-way though.
[05:08] <coppro> lol
[05:08] <RAOF> Write to a frikkin temporary file, then assume atomic renames, damnit!
[05:11] <NCommander> coppro, it's been awhile since I used it
[05:11] <NCommander> Check bash's manpage
[05:11] <coppro> ok
[05:11] <coppro> thanks for the advice though
[05:18] <coppro> is a MOTU around?
[05:19] <StevenK> Many are. They didn't put their hands up, so just ask your question.
[05:20] <coppro> I need a REVU upload nuked
[05:20] <coppro> because I realized the source package is named completely inappropriately
[05:20] <coppro> so I plan on reuploading under a different name
[05:22] <StevenK> Then that isn't an MOTU you're after. You're after a REVU admin
[05:22] <coppro> oh
[05:23] <coppro> I wasn't aware there was a difference, seeing as MOTUs seem to hold ultimate power
[05:23] <coppro> I guess I'll just post a comment on the upload then
[05:24] <StevenK> They only seem to, since they advocate or veto uploads and then throw them to the archive.
[05:25] <Hobbsee> motu's should be able to archive them.
[05:26] <coppro> they also update the keyring
[05:26] <StevenK> MOTUs don't update the keyring. :-)
[05:26] <RAOF> Nope, not me.  REVU admin only :)
[05:26] <Hobbsee> which p ackage?
[05:26] <coppro> libmk4
[05:26] <Hobbsee> done
[05:28] <coppro> ty
[05:34] <NCommander> RAOF, your a REVU admin?
[05:34] <NCommander> Cool ;-)
[05:36]  * NCommander continues to hack away on REVU
[05:38] <NCommander> Anyone know how I can get the current time in Python in a string?
[05:39] <RAOF> There's allways os.command :)
[05:39] <NCommander> ew
[05:39] <RAOF> Alternatively, the datetime module is likely to be your friend :)
[05:39] <NCommander> RAOF, have you seen my current REVU work?
[05:39] <jmarsden> NCommander: I think you want to use asctime ?
[05:40] <RAOF> No, I haven't.  (Nor am I a revu admin)
[05:40] <StevenK> time.strftime("%H:%m")
[05:40] <StevenK> '14:07'
[05:40] <NCommander> I just want to be able to do print timestamp, or something equivalent
[05:40] <NCommander> That'll do
[05:40] <StevenK> That might actually be month
[05:40] <jmarsden> ctime(None) should also work :-)
[05:40] <StevenK> It is. %M
[05:41] <NCommander> http://img172.imageshack.us/my.php?image=screenshotpk3.png
[05:41] <NCommander> http://img237.imageshack.us/my.php?image=screenshot2iy8.png
[05:41] <NCommander> http://img247.imageshack.us/my.php?image=screenshot3ay3.png
[05:41] <NCommander> Check it out
[05:44] <RAOF> NCommander: Funky!
[05:44] <RAOF> Does that also copy across buildlogs?
[05:44] <NCommander> RAOF, that all works, its at the point where its now (somewhat) downloading packages via dget
[05:44] <NCommander> RAOF, I plan to implement it
[05:44] <NCommander> if possible
[05:45] <NCommander> LP seems to have a random number in the build path so it may not be fessible
[05:45] <NCommander> (then again, the FTBFS package manages to make it work so I dunno)
[05:45] <RAOF> I suppose the ideal plan would be bi-directional PPA integration - build all revu uploads in a PPA & run lintian against the binaries, too.
[05:46] <NCommander> That was the original game plan actually
[05:46] <NCommander> But the space limitations would make it difficult to implement
[05:46] <NCommander> you'd be amazed how fast one gigabyte of PPA space can just disappear
[05:47] <jmarsden> NCommander: If there are real benefits, you can ask for more PPA space
[05:47] <NCommander> jmarsden, there also is no way I can automate cleaning out the PPAs and such
[05:47] <NCommander> not unless Soyuez has a SOAP or something based API I overlooked
[05:48] <NCommander> StevenK, what do you recommend as a good timestamp for a log (I used that to implement timestampings in the import_ppa_pkgs_daemon)
[05:50] <jmarsden> NCommander: Maybe %Y-%m-%d %H:%M:%S
[05:51] <jmarsden> NCommander: Or if you like ISO 8601,  %Y-%m-%dT%H:%M:%S
[05:51] <NCommander> 2008-07-21 00:51:38: Importing codeblocks from PPA group sonicmctails
[05:51] <NCommander> Nah, that's good :-)
[05:52] <NCommander> jmarsden, I won't mind being able to create a buildd off the REVU packages once a contributor OKs it for build
[05:52] <NCommander> (I don't want the buildds running a hidden rm -r /)
[05:53] <jmarsden> NCommander: Run them in a chroot as protection?  Can that be done?
[05:53] <NCommander> jmarsden, that's how buildds work
[05:53] <NCommander> But its an annoyance to rebuild the chroot
[05:53] <NCommander> sbuild is really stupid
[05:53] <NCommander> LIke
[05:53] <NCommander> Amazingly stupid
[05:53] <NCommander> and my python doesn't seem to have a chdir() in os
[05:54] <StevenK> Er, what?
[05:54] <NCommander> NameError: global name 'chdir' is not defined
[05:54] <NCommander> I have imported os
[05:56] <jmarsden> Ummmm try os.chdir(whatever)
[05:56] <RAOF> "from os import *" or "import os"?  If the latter, it'll be os.chdir
[05:56] <NCommander> Oh
[05:56] <NCommander> Thanks
[05:56]  * NCommander is still somewhat of a python newbie
[05:56] <StevenK> That's just namespacing :-)
[05:57] <NCommander> yeah
[05:57] <NCommander> Well, this is coming along very nicely
[05:57] <NCommander> Packages now get downloaded, and pop the row right out the DB
[05:57] <RAOF> But other languages handle things differently (looks at C#)
[05:57] <NCommander> Now I just need to make it import it into the database, and we have a feature complete (if not bug free) PPA importer
[05:58] <NCommander> RAOF, if you'd be interested in helping implement build server support, it would be rather awesome
[05:59] <NCommander> (I need someone who can host an i386/amd64 buildd; REVU is on a sparc machine, and I don't want a buildd server on the same place as the webserveR)
[06:05] <RAOF> I'd want to play with virtualisation to host that, and I may need a little more HDD (I'd want a full mirror, certainly).
[06:06] <RAOF> I'm probably not your first choice for the buildd hosting.
[06:06] <NCommander> RAOF, well, I'm still not that far, I'd like to get this ppa_import_daemon written first
[06:07] <NCommander> But I hear importing from PPA is a highly requested feature ...
[06:40] <NCommander> AND SCORE!
[06:46] <RAOF> Woot!
[06:47] <warp10> Hi all!
[06:54] <NCommander> RAOF, Packages can now be imported right from launchpad
[06:54] <NCommander> It all works!
[06:54] <RAOF> Awesome.
[06:54] <RAOF> I reackon a lot of people will like that.
[06:56] <NCommander> It still needs quite a bit of TLC
[06:56] <NCommander> But now we're at "working prototype"
[06:56] <NCommander> It's also a HELL of a lot faster then the dput method since its *download time*+*lintian time*+30 secs
[06:56] <NCommander> max
[07:34] <\sh> moins
[07:40] <\sh> siretart: didn't we had the discussion about debescan long time ago?
[08:17] <elmargol> I search a tutorial for a pristine git repository
[08:30] <Iulian> cody-somerville: ping
[08:30] <cody-somerville> Iulian, pong
[08:32] <Iulian> cody-somerville: Could you please have a look at salasaga? If I add the upstream's clean rule it won't even build.
[08:33] <cody-somerville> Iulian, pastebin your build log please showing me the failure
[08:33] <Iulian> One sec
[08:35] <Iulian> cody-somerville: http://paste.ubuntu.com/28928/plain/
[08:42] <cody-somerville> Iulian, instead of testing for existance of Makefile, look for Makefile.config
[08:44] <Iulian> cody-somerville: Done and uploaded
[08:52] <Iulian> Oups, forgot the add clean.
[08:52]  * Iulian is asleep.
[08:53] <Iulian> cody-somerville: Now it should be ok.
[09:05] <huats> morning everyone
[09:05] <huats> Syntux: hey Syntux
[09:36] <rohan> the version of eclipse in ubuntu is very very old. is there any specific reason for this? is eclipse difficult to package?
[09:46] <jpds> rohan: Appears to be little activity in Debian: http://tinyurl.com/6lfwma
[09:46] <rohan> hehe, now the upstream version is 3.4
[09:47] <rohan> jpds: but why should that prevent ubuntu from going up to a newer version?
[09:47] <directhex> it shouldn't, but it means ubuntu doesn't get anh update "for free"
[09:47] <rohan> ah, yes
[09:49] <directhex> the best route in theory is to make an updated debian package  submit it to the debian project - then pull that down into ubuntu
[09:49] <directhex> in practice, the last step is often blocked by general lack of sponsors
[09:49] <rohan> but ubuntu frequently has packages newer than debian - gnome, for example
[09:52] <Syntux> huats, hey
[09:52] <geser> Debian is freeze next week, so don't expect to see new upstream versions there soon
[09:53] <rohan> exactly
[09:54] <huats> Syntux: I will have a look at your patch this morning...
[09:54] <Syntux> okie
[09:56] <directhex> i've had a few new debian packages added very recently, but a stony silence on syncing to intrepid
[09:56] <geser> directhex: are sync requests filed?
[10:00] <Syntux> huats, Maybe next time we should discuss the expected result instead of sending patch for review.
[10:00] <huats> Syntux: we can
[10:00] <directhex> https://bugs.launchpad.net/ubuntu/+source/xsp/+bug/243723 and https://bugs.launchpad.net/ubuntu/+source/mod-mono/+bug/248930
[10:00] <rohan> any hope for eclipse to be updated in intrepid, then/
[10:00] <huats> Syntux:did you get my email ? (I mean the one I sent you yesterday)
[10:00] <Syntux> huats, no
[10:00] <directhex> ignore the fix released, the original bug was misfiled
[10:01] <huats> Syntux: hum...
[10:01] <directhex> rohan, if you hurry, perhaps
[10:01] <didrocks> hi everyone, does somebody has already tried to use pbuilder behind a proxy with authentification?
[10:01] <rohan> directhex: if someone can teach me how to package eclipse, then i'm game! :)
[10:02] <didrocks> I tried a lot of stuff (first, with wget) and my conclusion is the only way to make it working is to put http_export='http://proxy:port' and wget --proxy_login '...' --proxy_passwd '...'
[10:02] <Syntux> huats, oh that kind of relationship affects the development cycle of Ubuntu and thus should be avoided
[10:02] <Syntux> huats,  :p
[10:02] <NCommander> morning directhex
[10:03] <huats> Syntux: :)
[10:03] <Syntux> ops
[10:03] <didrocks> using http_proxy='http://login:pass@proxy:port' seems to not work with wget, so, with pbuilder...
[10:03] <directhex> hello NCommander
[10:04] <stgraber> directhex: pbuilderrc has an option for http proxy
[10:04] <stgraber> argh, didrocks ^
[10:04] <directhex> really? neat!
[10:04] <NCommander> directhex, my mono fix is still stuck on launchpad
[10:04] <didrocks> stgraber: yes, but as I have to use authentification, I tried --http_proxy='http://login:pass@proxy:port' and it does not work
[10:05] <didrocks> stgraber: the only way to make it work (regarding my tests with wget) is to user seperate option for login like --http_login
[10:06] <directhex> NCommander, bleh.
[10:06] <directhex> NCommander, too many cooks, not enough waiters!
[10:06] <stgraber> the only proxy option I see in pbuilder's man is --http-proxy ...
[10:06] <NCommander> directhex, On the plus side, I have coded up a rather cool feature for REVU ;-)
[10:06] <StevenK> NCommander: Mono fix?
[10:07] <directhex> NCommander, detect apps related to mono and report them as evil freedom-hating terrorism?
[10:07] <didrocks> stgraber: exactly, that's why I ask if somebody has already experienced that :)
[10:07] <NCommander> StevenK, to solve the f-spot.app segfault, quite a few mcs seg faults, and solve an FTBFS
[10:07]  * StevenK smirks
[10:07] <StevenK> NCommander: On intrepid, or hardy?
[10:07] <NCommander> intrepid, but hardy is also effected
[10:07] <NCommander> *affected
[10:08] <NCommander> Hold on, let me grab the bug report
[10:08] <StevenK> NCommander: Okay, so, the first step is to fix intrepid. Then prepare an SRU for hardy?
[10:08] <NCommander> THe debdiff been on Launchpad for a wiki
[10:08] <NCommander> And main sponsors are subscribed, no life
[10:08] <NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/mono/+bug/247782
[10:09] <NCommander> I created the debdiff for intrepid, but I wasn't sure if it was SRU worthy
[10:10] <NCommander> StevenK, it was an absolute nightmare to run down that bug
[10:10]  * NCommander wishs LP allowed normal users to set importances just like Debian ...
[10:10] <directhex> simple backporty SRUs aren't permitted under the "no framework updates damnit" policy. hardy would need its own updated version of 1.2.antiquewhatever
[10:10] <NCommander> directhex, its the same patch that has to be replaced
[10:10] <NCommander> Because whoever coded the first one should be taken out back and shot
[10:11] <NCommander> You don't solve a bug by commenting out an entire function
[10:12] <NCommander> More information on what the original patch tried to fix, and how my replacement one is less braindead is there
[10:12]  * directhex looks sheepish, hides remove_arg_max_check_r101444.dpatch
[10:12] <directhex> to be fair, THAT one's from upstream
[10:12] <geser> NCommander: my experience with main sponsors is that you should hunt down a sponsor yourself, unless dholbach "assigns" a core-dev to it (and dholbach is currently on holidays)
[10:13] <NCommander> geser, I tried, and most ran in fear of mono
[10:13] <directhex> geser, good point, how about my xsp/mod-mono updates? them's in yooniverse!
[10:13] <StevenK> I'm willing to upload it
[10:13] <geser> NCommander: yes, for some packages it hard to find a sponsor
[10:13] <NCommander> which is understandable but unfortunate
[10:13] <directhex> NCommander, well, of course. mono eats babies.
[10:13] <NCommander> StevenK, its been tested on the liveCD, which was ABSOLUTE fun
[10:13]  * NCommander had to eventually setup an NFS server just to have enough room to build mono
[10:14] <NCommander> er, replace
[10:14] <StevenK> I just have an issue with the patch
[10:14] <NCommander> which is?
[10:14] <StevenK> const char* prefixes[] = {"/cow/", "/persistmnt/", "/rofs/", "/rwfs/", "/squashmnt/", NULL};
[10:14] <directhex> it's pretty much the same patch as applied to ubuntu's java packages to make them work on the livecd
[10:15] <NCommander> It is the same patch
[10:15] <StevenK> Oh, ew
[10:15] <NCommander> Well, this bug is caused by unionfs
[10:15] <directhex> yes, ew
[10:15] <directhex> blame unionfs
[10:15] <NCommander> It prevents the symlink from coming out right
[10:15] <StevenK> Right, it's essentially a unionfs bug
[10:15] <StevenK> I thought intrepid was using aufs?
[10:15] <NCommander> THere is a patch for the unionfs bug
[10:15] <NCommander> But kernel upstream will not include it
[10:15] <directhex> which is broken by design, but less likely to get fixed than patching every single app in ubuntu to avoid the problem
[10:15] <NCommander> and ubuntu-kernel bounced it
[10:15] <StevenK> unionfs is in LUM
[10:16] <directhex> go figure
[10:16] <NCommander> No, they did it with good reason
[10:16] <StevenK> Oh?
[10:16] <NCommander> To "fix" the issue, they gave the kernel a root canel
[10:16] <NCommander> IT was UGLY
[10:16] <geser> directhex: I see only a sync request for mod-mono (bug 248930). Is there also one already for xsp?
[10:16] <NCommander> It wasn't a trival patch
[10:16] <NCommander> it was a few hundred or thousands lines changing unionfs and the core modules
[10:17] <directhex> geser, LP:243723
[10:17] <StevenK> NCommander: Still, isn't Intrepid using aufs?
[10:17] <NCommander> StevenK, the liveCD I tried was unionfs AFAIK
[10:18] <NCommander> but the intrepid CD I had might have been out of date
[10:18] <StevenK> I heard murmurs of aufs
[10:18] <NCommander> so did I
[10:18] <NCommander> But it looks like aufs has issues
[10:18] <StevenK> So does unionfs :-)
[10:18] <NCommander> http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg918853.html
[10:19] <NCommander> Well, the patch still needs to be backported to hardy
[10:19] <NCommander> Unless you want five years of random mono failures
[10:19] <directhex> honestly, nobody who seriously uses mono uses the antique ubuntu packages
[10:19] <StevenK> I note that bug is closed
[10:19] <directhex> no Enterprise dist has the same rigidity for updating frameworks
[10:20]  * NCommander blinks
[10:20] <geser> directhex: need just mod-mono and xsp get updated? no other packages needing also an update?
[10:20] <NCommander> StevenK, which bug
[10:20] <directhex> geser, none on my to-do list. unless you can sponsor main packages, and make NCommander happy ;)
[10:20] <StevenK> NCommander: The URL you pasted, Bug 248164
[10:21] <NCommander> Ah
[10:21] <NCommander> Looking at Launchpad
[10:21] <NCommander> the LiveCD now has support for aufs, but the desktop/server teams haven't made the switch yet
[10:22] <geser> directhex: no, I can't sponsor main. I need to find sponsors for 2 packages myself.
[10:23] <NCommander> Ick
[10:23] <NCommander> aufs is based off unionfs's
[10:23] <NCommander> ^code
[10:23] <NCommander> I REALLY won't be suprised if it is effected by the same bug
[10:25] <NCommander> StevenK, regardless, the patch does require backporting to hardy, and until unionfs is dead and buried, it probably should be intrepid
[10:25] <NCommander> We could remove the patch cold-turkey, and then the liveCD team going to get bitchy if mono breaks on them
[10:25] <StevenK> NCommander: Sure, but what about different path prefixes?
[10:26] <NCommander> StevenK, It seems that unionfs can return one of a few different path locations ;-)
[10:26] <StevenK> Which are there already.
[10:26] <directhex> my long-term goal is to end merging in favour of syncing
[10:26] <StevenK> I so need to learn to read.
[10:26] <NCommander> Its a direct port of the patch the OpeJDK guys applied after fighting through this
[10:27] <directhex> but it won't happen in the 1.9.1 timeframe, and can't happen as long as there's this unionfs silliness
[10:27] <directhex> also need some libdga gubbins to sort itself out, but that's another story
[10:28] <StevenK> NCommander: You suck, mono is a 24MB source package.
[10:28] <NCommander> You now know why every other sane MOTU ran
[10:28] <NCommander> er, core-dev
[10:28] <NCommander> StevenK, please don't tell me your on dial up ...
[10:29] <directhex> it's smaller than openjdk!
[10:29] <NCommander> directhex, at least openjdk is useful
[10:29] <NCommander> *rimshot*
[10:30] <directhex> don't start, i just read the 18 page "no mono by default" forum page
[10:30] <NCommander> directhex, BTW, I assume you haven't seen REVU's newest feature?
[10:30] <NCommander> directhex, a "fun" read
[10:30] <directhex> NCommander, nay. i've not used revu, since everything i do is updates or happens in debian first
[10:30] <NCommander> I think StevenK's seen it
[10:32] <directhex> so my "detect mono and call you scum" idea isn't it? damn
[10:34] <StevenK> NCommander: Worse. Australia
[10:34] <NCommander> StevenK, having fun with Big Pond ;-)
[10:34] <NCommander> It's a pity f-spot is such an easy photo manager, or else I'd vote to kick it out of main and use a different photo manager
[10:34] <StevenK> Nope, I don't use BigPond
[10:35] <StevenK> NCommander: Tomboy also uses mono
[10:35] <NCommander> *sigh*
[10:35] <NCommander> Packaged evil
[10:35] <NCommander> StevenK, BTW, did you see the new REVU feature screenshots?
[10:36] <directhex> don't forget terrorism and hate
[10:36] <StevenK> NCommander: I saw one of them
[10:36] <NCommander> http://img172.imageshack.us/my.php?image=screenshotpk3.png
[10:36] <NCommander> http://img237.imageshack.us/my.php?image=screenshot2iy8.png
[10:36] <NCommander> http://img247.imageshack.us/my.php?image=screenshot3ay3.png
[10:36] <NCommander> It works now
[10:36] <StevenK> But I don't use REVU much :-P
[10:36] <NCommander> Packages get sucked from the PPA and right into REVU in about 20 seconds
[10:36] <geser> directhex: sync requests for mod-mono and xsp ACKed.
[10:36] <NCommander> StevenK, nah, I understand, but I like using my bragging rights
[10:36]  * NCommander points to the badges on LP
[10:37] <StevenK> NCommander: "your already" -> "you're already"
[10:37] <directhex> geser, huzzah!
[10:37] <NCommander> when did I say your already?
[10:37] <StevenK> In the text in http://img247.imageshack.us/my.php?image=screenshot3ay3.png
[10:37] <NCommander> Oh ...
[10:37] <NCommander> Well, its a beta ;-)
[10:38] <StevenK> irc.freenode.net, too
[10:39] <NCommander> :-P
[10:39]  * NCommander adds a bug to launchpad
[10:39] <NCommander> "I make mistakes while tired" [Confirmed, Critical]
[10:39] <directhex> hm, i wonder what'll happoen if mod-mono tries to build before xsp.
[10:39] <NCommander> StevenK, I didn't know you worked at canonical
[10:44] <wgrant> directhex: It doesn't, because you have build-dependencies set properly. I hope.
[10:47] <directhex> wgrant, well, that's where it gets interesting really. there's no build-dep, there's a substitution in the binary depends in the control file. i wonder where it gets those from. hmmm...
[10:47] <StevenK> NCommander: Hm?
[10:47] <wgrant> directhex: There is a build-dep.
[10:47] <wgrant> Or it won't build.
[10:47] <StevenK> NCommander: And? :-)
[10:47] <NCommander> It's got to be awesome to be able to work at canonical on Ubuntu
[10:47] <wgrant> StevenK: You are now an Evil One, see.
[10:48] <StevenK> Apparently.
[10:48] <directhex> Build-Depends: debhelper (>= 4.1.16), apache2-threaded-dev (>= 2.2), libmono-dev, po-debconf
[10:48]  * NCommander doesn't find StevenK evil
[10:48] <directhex> anyway, looks like the substitution is based on debian/changelog, which is safe enough
[10:48] <wgrant> directhex: If it doesn't build-depend on it, it won't matter what order they're built in.
[10:48] <directhex> so no worries
[10:48] <NCommander> If nothing else, he's a saint for actually downloading mono's tarball over an AU internet connection
[10:50] <directhex> perhaps i've grown numb to it, after 2 years of unofficial backports
[10:50] <StevenK> Ooh, mono builds
[10:50] <directhex> that & a university internet connection, and all the compute power money can buy
[10:50] <StevenK> Ish
[10:51] <directhex> StevenK, ish? i need to know about ishes. ishes cause me and debian-mono stress.
[10:51] <NCommander> StevenK, ish?
[10:52] <wgrant> Mono causes everybody stress.
[10:52] <StevenK> Ish == it's gotten into binary, but hasn't finished yet
[10:52] <NCommander> ow
[10:52] <NCommander> StevenK, I think you might need a new PC
[10:52] <directhex> wgrant, it causes boycott-novell.com stress. the rest of us it's only mild anxiety
[10:52] <StevenK> NCommander: Feel free to provide one.
[10:52] <StevenK> :-P
[10:53] <directhex> this sounds like a job for MOAR MHZ!
[10:53] <NCommander> StevenK, you cold always just upload to your PPA
[10:54]  * NCommander reads boycott novell
[10:55] <directhex> it's like bullshit and chips, but with a bit more bile
[10:55] <StevenK> NCommander: Meh.
[10:55] <directhex> it works hard on the internet principle that if you say it, and even link directly to something that shows you're wrong, it's still true
[10:57] <directhex> hm, i need to update my backport. i wonder what i changed in ~dhx2
[10:59]  * NCommander looks at StevenK's computer
[11:00] <StevenK> Still building
[11:00] <NCommander> impressive
[11:25] <directhex> for future reference, it seems PPAs take 10 minutes for the arch-dependent and 16 minutes for the arch-independant parts of mono
[11:26] <directhex> give or take
[11:26] <laga> that's fast
[11:26] <NCommander> I can get it built in ~20 minutes here total
[11:26] <foka> Very fast build daemons?  :-)
[11:27] <NCommander> foka, just a fast laptop
[11:27] <foka> NCommander, Very cool!  :-)
[11:28] <NCommander> My old laptop was a 2.16GHz dual core with 2GB of RAM
[11:28] <NCommander> I got that one in '05
[11:28] <directhex> it's about 20 minutes for me too
[11:28] <NCommander> My current one is a 2.30Ghz dual core with 2GB of RAM
[11:28] <NCommander> This one cost a third of the old one
[11:28] <directhex> yay for technology!
[11:29] <NCommander> The old one probably could to become a build server for WMbuntu
[11:29] <directhex>   	 amd64 build of mono 1.9.1+dfsg-2ubuntu2~dhx1 in ubuntu hardy RELEASE
[11:29] <NCommander> s/could to/is going to
[11:29] <NCommander> I must be more tired then I realize
[11:30] <NCommander> the wiki running really poor today
[11:31] <directhex> probably novell's fault
[11:32] <NCommander> StevenK, would you agree this bug is SRU worthy?
[11:32] <StevenK> NCommander: I'm not certain, to be honest.
[11:32] <StevenK> Ugh. 44 minutes to build mono.
[11:33] <StevenK> And 650MB of disk space
[11:33] <directhex> StevenK, someone needs MOAR MHZ
[11:33] <NCommander> StevenK, well, the issue exists in Hardy
[11:33] <directhex> Build started 11 minutes ago  on promethium (xen-amd64)  and finished 1 minute ago  taking 11 minutes ? see the log
[11:33] <directhex> hurrah
[11:34] <StevenK> directhex: The hard disk in my workstation sucks
[11:34] <StevenK> NCommander: Uploaded
[11:34] <directhex> yay! cake for StevenK!
[11:34] <NCommander> Sweet
[11:34] <directhex> NCommander, oh, and thanks for your work on this. i'm always grateful when people are willing to sell their souls to help with mono-related tasks
[11:34] <NCommander> StevenK, can you give-back packages, or do I need to file a bug?
[11:35] <Hobbsee> NCommander: what do you need given back?
[11:35] <NCommander> evolution-sharp was FTBFS because of the mono bug
[11:35]  * Hobbsee pokes it
[11:35] <NCommander> Now that the formal finally got fixed, the later can be built once mono's updated binaries are available
[11:35] <NCommander> *former
[11:35] <Hobbsee> mmm, only amd64 and ppc failed.
[11:35] <NCommander> geser will be happy, he asked me to fix that bug.
[11:36] <NCommander> Hobbsee, it's an intermittent failure; it doesn't always happen
[11:36] <NCommander> Something like 75% of the time it will fail
[11:36] <NCommander> and the other 25% it won't
[11:36] <NCommander> That's why testing this package involved running dpkg-buildpackage in a loop ten times building the same package :-)
[11:37] <NCommander> Hobbsee, incidently, this appears to also be responsible for those random F-Spot segfaults, since those stopped for me once I applied the mono patch
[11:38] <Hobbsee> ah, nice.
[11:38] <NCommander> Hobbsee, if you look at the orignal patch, its absolutely braindead
[11:39] <NCommander> Hobbsee, are you a buildd admin by any chance?
[11:39] <Hobbsee> yes
[11:39] <NCommander> Maybe you can help me nail a bug then
[11:39] <NCommander> logwatch FTBFS on all archs aside from i386
[11:39] <NCommander> I've built it in pbuilder, sbuild, even setup a intrepid buildd, and it built
[11:39] <NCommander> But its FTBFSing on the launchpad buildds
[11:40] <Hobbsee> are you running an i386 arch?
[11:40] <NCommander> amd64; testing in an i386 chroot
[11:40] <NCommander> (it builds fine on both)
[11:40] <NCommander> http://launchpadlibrarian.net/16002155/buildlog_ubuntu-intrepid-amd64.logwatch_7.3.6.cvs20080702-1ubuntu1_FAILEDTOBUILD.txt.gz The log file is somewhat confusing on why its FTBFSing
[11:43] <geser> NCommander: have you also tried pbuilder build --binary-arch?
[11:43] <NCommander> --binary-arch?
[11:43] <NCommander> No, but I did run pbuilder on an amd64 and an i386, both successful
[11:46] <geser> NCommander: i386 builds both the arch-dependent and arch-independent parts, while the other just build the arch-dependent parts
[11:46] <Hobbsee> geser++
[11:46] <geser> and some errors appear only in the arch-dep parts
[11:46] <NCommander> geser++++
[11:47] <NCommander> That might explain it
[11:47] <geser> NCommander: in the case of logwatch, it's because Ubuntu changed the package for some reason from arch:all to arch:any
[11:47] <geser> see http://patches.ubuntu.com/l/logwatch/logwatch_7.3.6.cvs20080702-1ubuntu1.patch
[11:47] <NCommander> O_o;
[11:48] <NCommander> o_O;, if its perl ... WHY THE HELL IS IT ARCH: ANY?
[11:48]  * NCommander hits his head on the wall a few dozen times
[11:48] <slytherin> NCommander: Careful or the wall will break. :-P
[11:49] <NCommander> I dunno, I'm up to my armpits in stupidity this week.
[11:49] <NCommander> if the wall hasn't given yet
[11:49] <slytherin> geser: Should I ask in #ununtu-devel for clearing batik from NEW?
[11:49] <NCommander> I don't think its going to
[11:49] <Hobbsee> slytherin: is it urgent?
[11:49] <Hobbsee> i think it's an archive admin day tomorrow
[11:49] <NCommander> Hobbsee, speaking of the archive
[11:50] <slytherin> Hobbsee: if 3-4 packages have depwait on batik then do you call it urgent?
[11:50] <NCommander> I need to ask a quesiton of an archive admin;
[11:50] <wgrant> slytherin: Just wait for them to get to it, I suggest.
[11:50] <wgrant> It has FTBFS for approximately ever, so I'm sure 24 hours won't hurt.
[11:50] <Hobbsee> NCommander: ask in #ubuntu-devel, probably
[11:50] <geser> Hobbsee: isn't every day (except the weekend) an archive day?
[11:51] <slytherin> wgrant: Are you sure it will be done in 24 hours?
[11:51] <geser> slytherin: today is slangasek's archive day, I guess he's not awake already
[11:51] <wgrant> slytherin: Maybe not.
[11:51] <Hobbsee> geser: i thought there were only 3 archive days with dedicated people, but i may be wrong
[11:51] <geser> Hobbsee: https://wiki.ubuntu.com/ArchiveAdministration lists 4 days
[11:52] <slytherin> Hobbsee: There are four
[11:52] <Hobbsee> slytherin: universe based?  no, not really
[11:52] <Hobbsee> ah, i thought riddell wasn't doing his shift anymore.
[11:53] <\sh> NCommander: depends what perl module..you can have perl modules with compile stuff which is arch dependant...so Arch: any and not Arch: all
[11:53] <NCommander> \sh, no, that I know
[11:53] <slytherin> I will ask on #ubuntu-devel anyway. If it is done, I can get to the dependent packages. Otherwise I will have to wait.
[11:53] <wgrant> slytherin: Why are you blocked on it? Upload them, and they should depwait!
[11:54] <\sh> NCommander: so in debian/control: you have Architecture: all? and moved all building stuff into binary-indep?
[11:55] <NCommander> \sh, my guess is that it was an Arch: all package that required building on i386, but the end result was portable
[11:55] <NCommander> I've seen one or two modules like that
[11:55] <slytherin> wgrant: There are few packages with DEPWAIT due to batik. Adn since batik had FTBFS forever we don't know if these packages build at all. I am specifically interested in fop.
[11:58] <\sh> NCommander: well, arch: all means calling sbuild with -A (which can be done on any arch sbuild runs), which actually is running on the i386 sbuild in ubuntus case
[11:58] <NCommander> I'm going to probably have to rip logwatcher's guts open and see why its failing
[12:02] <geser> NCommander: it has nothing to do in binary-arch
[12:04] <geser> NCommander: just changing logwatch back from arch:any to arch:all should fix it
[12:05] <geser> but you need a main sponsor to get it uploaded
[12:06] <NCommander> StevenK, up for another one?
[12:12] <kaminix_> Boohoo, no answers to my mail to the list today :(
[12:14] <k0p> I want include a directory in debian named patches/
[12:14] <k0p> but it does appear in diff file
[12:15] <k0p> what should I do?
[12:15] <NCommander> k0p, you need to have some patches in the directory ;-)
[12:15]  * k0p die
[12:15] <k0p> :@
[12:15] <k0p> sure!
[12:16] <k0p> forget copy it :\
[12:16] <k0p> lol
[12:16] <NCommander> just saying that having an empty directory is kinda pointless
[12:17] <k0p> yeah
[12:39] <k0p> NCommander, it does apply patches.. hmm
[12:40] <k0p> i'm following this: https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[13:25] <bdrung> geser: thanks for your xmms-related remove acknowledgements
[13:29] <emgent> moin
[14:08] <\sh> bah bandwidth...if this is really a problem nowadays...
[14:10] <directhex> bandwidth is easy. i could always use MOAR MHZ though
[14:11] <\sh> directhex: I was more talking about the debescan issue on ubuntu-motu ml
[14:11] <directhex> i tend to avoid mailing lists. i keep trying to unsubscribe from gridengine-users but sun won't let me
[14:14] <\sh> who needs a grid when we have a matrix ;)
[14:15] <directhex> or a 256 core altix 4700
[14:34] <huats> Syntux_: are you around ?
[14:38] <abogani> Someone could review my package rt-test (http://revu.ubuntuwire.com/details.py?package=rt-tests) on REVU, please? I think to be very near to an "acceptable" version... Thanks in advance.
[15:37] <bddebian> Heya gang
[15:40] <geser> Hi bddebian
[15:43] <bddebian> Heya geser
[15:51] <Iulian> Hey bddebian
[15:52] <bddebian> Hi Iulian
[15:56] <huats> norsetto !
[15:56] <huats> (got you)
[15:56] <norsetto> huats: argh!
[15:56] <norsetto> huats !
[15:57] <huats> ;)
[15:58] <norsetto> huats: looks like there is some stuff pending approval in the m.l.?
[15:59] <huats> norsetto: ?
[15:59] <huats> really ?
[15:59] <norsetto> huats: I think so
[16:03] <abogani> Someone could review my package rt-test (http://revu.ubuntuwire.com/details.py?package=rt-tests) on REVU, please? I think to be very near to an "acceptable" version... Thanks in advance.
[16:19] <cody-somerville> \sh, ugh oh! You're in trouble! :P
[16:20] <\sh> cody-somerville: I'm always in trouble...I'm a sysadmin..
[16:20] <\sh> cody-somerville: what context? :)
[16:21] <cody-somerville> \sh, MagicFab is "invoking" the CoC on ya.
[16:22] <\sh> cody-somerville: so? he doesn't have the guts to remove my feed from the planet ,-)
[16:22] <\sh> by himself
[16:22] <cody-somerville> lol
[16:22] <cody-somerville> \sh, I'd do it myself in spite of that comment but I'd rather see your blog stay on the planet,haha.
[16:23] <cody-somerville> I have no idea what his problem is with that iPod blog post though :/
[16:23] <\sh> which ipod blog post?
[16:23] <\sh> that's long timea ago...
[16:23] <\sh> cody-somerville: btw...any reference to that?
[16:24] <cody-somerville> \sh,any reference to what where? : P
[16:24] <\sh> cody-somerville: I thought he wrote something to the CC about me...
[16:25] <cody-somerville> \sh, yea, he posted on the wiki
[16:25] <\sh> ROTFL
[16:27] <\sh> I find it rather nice...someone puts something on a wiki page without pinging the someone who is being blamed for this something...
[16:29] <cody-somerville> \sh, well, clearly magicfab misunderstand something because we don't "invoke" the CoC on people.
[16:33] <cody-somerville> \sh, I wouldn't worry about it IMHO
[16:36] <\sh> cody-somerville: about what?
[16:38] <\sh> cody-somerville: where is this second blog post he talks about on https://wiki.ubuntu.com/CommunityCouncilAgenda/talk ? I just see one?
[16:38] <cody-somerville> \sh, Yea, he removed the second one. He "cleared up his dispute".
[16:38] <cody-somerville> The blog post was this one: http://koke.amedias.org/articles/2008/07/20/ibuy/
[16:39] <\sh> aye
[16:39] <\sh> he framed koke
[16:39] <cody-somerville> framed? :/
[16:41] <\sh> cody-somerville: he pinned someone...
[16:42] <cody-somerville> \sh, yes I understand what framed means but I'm not sure I see how.
[16:44] <\sh> cody-somerville:
[16:44] <\sh> Fabian Rodriguez Jul 21 2008 / 3pm
[16:44] <\sh> Jorge, I don’t appreciate your “STFU” responses on a blog post syndicated on Ubuntu Planet. How is that within our Ubuntu code of conduct in any way ?
[16:44] <\sh> Quite frankly I am really disappointed at your attitude, as indeed this has nothing to do with Ubuntu, but now you’ve elevated it to going against our code of conduct.
[16:44] <\sh> he put words in kokes mouth...
[16:45] <\sh> I really think he needs a beer and a life
[16:45] <cody-somerville> : (
[16:47] <\sh> cody-somerville: the fun part...he talks about comments, and that's why he filed somewhat? argl../me needs to fix leonov...
[16:47] <huats> \sh: i have always like your tone ... keep it up :)
[16:48] <\sh> when is the next CC meeting?
[16:50] <\sh> tomorrow?
[16:50] <\sh> no...next month...
[16:54] <devfil> asac: I'm looking at xulrunner, the version on the repo is 1.8.1.14 but at http://developer.mozilla.org/en/docs/XULRunner/Old_Releases I can see only 1.8.1.3 so what I should do?
[16:56] <asac> devfil: you have to get the latest release from cvs
[16:56] <asac> they dont release tarballs regularly upstream
[16:57] <devfil> asac, ah ok,  and how I should call it?
[16:58] <asac> devfil: instructions on cvs are http://developer.mozilla.org/en/docs/Mozilla_Source_Code_Via_CVS
[16:58] <asac> devfil: the tag is MOZILLA_1_8_1_15 release (or 16? ... whatever latest firefox minor version is)
[16:59] <asac> and the MOZ_CO_PROJECT=xulrunner
[16:59] <devfil> ok
[17:00] <asac> when you have the source tree run remove.nonfree script that is in debian/ dir of xulrunner package
[17:08] <ryanakca> Anybody mind reviewing my kde-style-qtcurve merge (REVU) before I upload the debdiff to LP? http://revu.tauware.de/details.py?package=kde-style-qtcurve
[17:14] <norsetto> ryanakca: just upload your debdiff to LP, whats the point of using REVU for this
[17:19] <devfil> asac: if I use cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -r MOZILLA_1_8_1_16 mozilla/client.mk the outoput of the terminal is cvs [checkout aborted]: no such tag MOZILLA_1_8_1_16
[17:20] <asac> devfil: ok, then be tricky and use the firefox _16 tag
[17:20] <asac> e.g. FIREFOX_2_0_0_16_RELEASE
[17:21] <asac> not nice, but i think upstream stopped tagging the generic MOZILLA_1_8_BRANCH at some point
[17:21] <devfil> instead of RELEASE what I should put?
[17:21] <asac> devfil: the tag would be MOZILLA_1_8_1_16_RELEASE
[17:21] <asac> devfil: nothing. thats how the tag reads
[17:22] <asac> devfil: there is a tags page linked from the instructions page i gave you
[17:22] <asac> but those are not complete so give  the mozilla tag a proper try before going for the FIREFOX thing
[17:24] <devfil> asac, with cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -r MOZILLA_1_8_BRANCH mozilla/client.mk works
[17:24] <asac> devfil: yes. the branch exists
[17:25] <asac> devfil: in times before they made MOZILLA_ tags for thatgeneric branch
[17:25] <asac> devfil: if MOZILLA_1_8_1_16_RELEASE doesnt exist you have to use the FIREFOX relase tag
[17:25] <asac> which should be more or less the same
[17:32] <ryanakca> norsetto_limbo: because I don't know if I merged it properly... or will it just get reviewed on debdiff?
[17:33] <ryanakca> s/debdiff/launchpad/g
[17:38] <devfil> asac, nothing to do, I'm unable to find the correct tag
[17:45] <asac> devfil: i gave you the firefox one above?
[17:45] <asac> FIREFOX_2_0_0_16_RELEASE
[17:45] <asac> 18:20 < asac> e.g. FIREFOX_2_0_0_16_RELEASE
[17:46] <Hew> What's the best way to contribute a small patch to language-support-writing-en (to fix bug #58308)? I'm not an experienced contributor, and looking at the naming scheme of the version, appending ubuntu1 doesn't seem appropriate.
[17:46] <devfil> asac, oh I've not read, thanks
[18:02] <norsetto> ryanakca: yes, it will get reviewed on LP, just subscribe ubuntu-universe-sponsors (if the package is in universe) or ubuntu-main-sponsors (if the package is in main)
[18:02] <ryanakca> norsetto: already uploaded to main :)
[18:02] <norsetto> ryanakca: good!
[18:02] <ryanakca> thanks ;)
[18:03] <k0p> hi
[18:03] <k0p> I have a doubt about python new policys
[18:04] <k0p> My application is develpment in python. and we have two modules: umitCore, and umitGUI ( Interface )
[18:04] <k0p> following this policys we need to create a package named python-umitcore and python-umitgui?
[18:13] <RainCT> k0p: no, that's only for modules, as in modules that are designed to be used by other programs (what in C would be a "library")
[18:13] <k0p> RainCT, yeap. sure. but what I should do with my package?
[18:13] <k0p> where I put the umitCore and umitGUI?
[18:20] <norsetto> emgent: ping
[18:20] <RainCT> k0p: (sorry, i was busy)
[18:20] <RainCT> k0p: do you have a link to the souirce?
[18:21] <k0p> yeap
[18:21] <RainCT> *source
[18:21] <k0p> RainCT, do you want source or link to revu?
[18:21] <k0p> no problem
[18:22] <k0p> RainCT, do you want source or link to revu?
[18:22] <k0p> http://revu.tauware.de/details.py?package=umit
[18:22] <RainCT> revu is ok :)
[18:22] <k0p> http://trac.umitproject.org/browser/trunk if you wish ..
[18:23] <emgent> norsetto: ponghe
[18:25] <RainCT> k0p: is umitcore intented to be used by other applications?
[18:26] <RainCT> k0p: if yes, then it might make sense to put that directory into a separate binary package (python-umitcore). else leave everything together in package 'umit'
[18:27] <k0p> RainCT, umitcore is used by other application
[18:28] <norsetto> RainCT: pyumit? Or is there other stuff there beside python?
[18:28] <k0p> but suppose that not used by other application where I can put the files?
[18:29] <k0p> /usr/lib/pythonX-X/site-packages/umitCore?
[18:29] <k0p> and umitGUI?
[18:30] <RainCT> norsetto: sorry?
[18:31] <norsetto> RainCT: The source package, what would be the convention, to call it pyumit if its just python stuff, or something else?
[18:31] <RainCT> norsetto: usually it's just the applications name
[18:33] <k0p> RainCT, but with umit, i'm putting the files on /usr/lib/pythonX-X/site-packages. should I do it?
[18:34] <k0p> i'm trying respect the python policys but I don't understand yet what it failing
[18:34] <RainCT> norsetto: there are many py<something> packages but I guess that's in most cases like that because that's how upstream called the application; perhaps there may be or there has been some convention which said to prepend py to the source package name, but if there is I'm not aware of it
[18:36] <RainCT> k0p: I'm not sure. For the python applications that I packaged the source is in /usr/share/<packagename>
[18:36] <norsetto> RainCT: ah ok, makes sense
[18:36] <k0p> RainCT, sure. ok
[18:37] <RainCT> k0p: I'd say /usr/lib/python.. is only for shared modules, but the best would be to ask in #debian-python (irc.oftc.net) to be sure
[18:37] <k0p> sure RainCT thanks
[18:38] <RainCT> k0p: you're welcome. btw, I'd add python-psyco as a Suggests
[18:38] <k0p> sure.
[18:38] <k0p> thanks
[18:38] <k0p> i'll do apt-get source python-psyoc
[18:39] <k0p> python-psyco
[18:40] <RainCT> k0p: no need to get the source for it. I mean adding a "Suggests: python-psyco" line to debian/control to indicate that the application supports psyco
[18:40] <RainCT> (psyco is an optimizer which can make Python applications faster -but using more memory-)
[18:41] <k0p> oh
[18:41] <k0p> sure
[18:41] <k0p> I understand
[18:41] <k0p> yeap
[18:41] <k0p> I forgot. Thanks RainCT :)
[18:41] <k0p> you're great
[18:42] <k0p> well. truth .. I don't know about suggests
[18:44] <k0p> RainCT, i'll awser in debian-python :)
[18:46] <RainCT> k0p: Well, you already know Depends, but beside those there are Recommends and Suggests. the first one is for packages that are necessary for the application to work, and the other two are for packages that can improve it, or which are necessary for only a certain feature of it.
[18:47] <RainCT> k0p: the difference between Recommends and Suggests is that Suggests are weaker than Recommends. eg, recommends are automatically installed by aptitude (and since intrepid, by apt-get, too) but suggests always have to be installed manually by the user, if he wants them
[18:47] <k0p> yeah
[18:47] <k0p> sure :D
[18:47] <k0p> since intrepid?
[18:47] <k0p> so later suggests and recommends?
[18:47] <k0p> have no differences?
[18:48] <RainCT> k0p: the difference is basically that, as I said, recommends are installed by default by some package managers, but suggests never are
[18:49] <k0p> hm sure
[18:49] <k0p> :)
[18:49] <k0p> I understand
[18:50] <k0p> RainCT, you're a very nice guy. ever I learn with you :)
[18:51] <RainCT> thanks :)
[19:23] <kirkland> i'm looking at opencryptoki...  according to http://packages.qa.debian.org/o/opencryptoki.html, 2.2.6+dfsg-1 has been in unstable for a few days, but http://merges.ubuntu.com/universe.html doesn't show the outstanding merge
[19:26] <geser> kirkland: why should it appear on merges.u.c? opencryptoki in intrepid has no Ubuntu changes
[19:26] <kirkland> geser: ah that would explain it, thanks.
[19:27] <Laney> kirkland: http://qa.ubuntuwire.com/multidistrotools/universe.html#outdatedinB
[19:28] <slytherin> geser: What all should we put in https://wiki.ubuntu.com/JavaTeam/TeamReport for this month?
[19:28] <kirkland> Laney: thanks for the link ;-)
[19:30] <geser> slytherin: good question. perhaps the new batik version in intrepid?
[19:31] <slytherin> geser: I am actually classifying whatever I have done in 2 sections. syncs/merges, updates. Whoever else has done any work in these two area can add comments.
[19:32] <slytherin> and of course openjdk in main is one important point.
[19:35] <geser> ah
[19:36] <slytherin> geser: By the way, LucidFox built batik with openjdk, so it should move to universe.
[19:38] <geser> slytherin: will you file a bug for it?
[19:39] <slytherin> geser: Or should we wait till package is updated in Debian? I also want to do a bit more experimenting and see if it builds with GCJ with a patch to replace sun specific apis.
[19:40] <geser> slytherin: like you want, you know more about java packages than me
[19:40] <Syntux> Hey, what to do with keys that starts with _ in .desktop file?
[19:41] <slytherin> Ok. I will be donw with it by weekend.
[19:59] <slytherin> geser: Can you please help fixing this FTBFS - http://launchpadlibrarian.net/15969377/buildlog_ubuntu-intrepid-i386.libmatthew-java_0.7.1-1_FAILEDTOBUILD.txt.gz
[20:00] <geser> slytherin: would unsetting LDFLAGS fix it?
[20:00] <slytherin> geser: no idea. Don't know much about gcc and ld. :-)
[20:01] <geser> slytherin: will try it later out, I'm in a meeting right now
[20:01] <slytherin> ok
[20:04] <slytherin> geser: FYI ... team report updated, see if you can add more content.
[20:07] <geser> slytherin: statcvs didn't move to universe yet, but a bug for it is open (bug #249894)
[20:10] <slytherin> geser: Corrected it. I am sleepy now. Good night. See you later.
[20:10] <geser> slytherin: good night
[20:13] <directhex> slytherin, -Wl,-Bsymbolic-functions should be passed to gcc, not ld
[20:13] <directhex> oh, arse
[20:13] <geser> directhex: it is set through LDFLAGS
[20:14] <geser> and other packages don't have a problem with it
[20:15] <directhex> geser, ld throws an error, gcc silently succeeds, with that flag. make of it what you will.
[20:28] <k0p> cody-somerville, are you there?
[20:30] <cody-somerville> k0p, maybe
[20:31] <k0p> cody-somerville, about your comment about debian policys http://revu.tauware.de/details.py?package=umit I'm think create python-umitcore and umit package
[20:31] <k0p> what do you think about that?
[20:32] <cody-somerville> k0p, why?
[20:33] <k0p> umitCore it's used by other applications
[20:33] <k0p> and restants I'll put it on /usr/share/umit
[20:33] <k0p> I think it's follow the python policys.
[20:34] <k0p> I already fix the patches, and desktop files
[20:34] <k0p> only lacks the python policys
[20:35] <k0p> cody-somerville, what do you think about ?
[20:39] <cody-somerville> k0p, I think your package needs work. :]
[20:39] <k0p> cody-somerville, I'm working
[20:40] <k0p> well may be I'll make a dput on some issues already fixed
[20:40] <k0p> but about python policys it's what I would like to know about it
[20:41] <Majost> Is there an easy way to get all the public keys for the package maintainers/submitters?
[20:44] <norsetto> emgent: news about my email?
[20:44] <emgent> not now, DktrKranz seems away..
[20:51] <norsetto> seems so far away
[20:51] <devfil> hi norsetto :(
[20:51] <devfil> s/(/)/
[20:51] <norsetto> Now it seems as though they're here to stay
[20:52] <norsetto> devfil: s/\(/\)/ :-)
[20:52] <devfil> norsetto: I'm not the ideal for special char on regex :P
[20:53] <devfil> norsetto: what's up?
[20:53] <norsetto> devfil: the sky ?
[20:53] <norsetto> devfil: the moon ?
[20:54] <devfil> norsetto: lol how are you?
[20:54] <norsetto> devfil: horribly well, and you?
[20:54] <NCommander> morning norsetto
[20:54] <devfil> norsetto: fine thanks ;)
[20:54] <norsetto> NCommander: hello NCommander
[20:55] <NCommander> norsetto, how are things for you?
[20:55] <norsetto> NCommander: difficult, I still have problems with fractions
[20:55] <NCommander> norsetto, it could be worse; atlest you can still package ;-)
[20:56] <norsetto> NCommander: can I!? Please don't spread the voice ;-)
[20:56] <devfil> NCommander: in Italy is evening :P
[21:44] <Jazzva> Can someone say that they claim no rights over program, and that the program is published under GPLv3?
[21:45] <RainCT> Jazzva: uh.. if I understood that right, it's contradictory -.-
[21:46] <Jazzva> RainCT, sounds to me that way too... but I just wanted to check that if maybe I'm wrong.
[21:46] <Jazzva> RainCT, thanks
[21:46] <mathiaz> kirkland: I've sponsored your lsb merge
[21:46] <kirkland> mathiaz: cool, thanks!
[21:46] <mathiaz> kirkland: next time, could you generate a .changes file that includes the changes in debian ?
[21:47] <kirkland> mathiaz: oh, sure
[21:47] <mathiaz> kirkland: http://people.ubuntu.com/~kirkland/lsb/merge-genchanges
[21:47] <mathiaz> kirkland: uses -v3.2-12ubuntu3
[21:47] <kirkland> mathiaz: hmm, i thought debuild -S did that, no?
[21:47] <mathiaz> kirkland: nope - by default debuild will only include the last changelog netry
[21:47] <Drk_Guy> Hi guys!
[21:47] <Drk_Guy> Where can i take a look at the different setcions?
[21:47] <mathiaz> kirkland: you have to specify -v3.2-12ubuntu3
[21:47] <Drk_Guy> I'm trying to package gambas2
[21:48] <neuromit> is is possible to configure  dpkg-buildpackage such that it creates 2 .deb files?
[21:48] <Drk_Guy> *sections
[21:48] <kirkland> mathiaz: gotcha, okay, no problem
[21:48] <neuromit> one package with a set a binaries and the other .deb with a different set of binaries?
[21:48] <Drk_Guy> neuromit, different archs?
[21:48] <neuromit> no same archs
[21:48] <mathiaz> kirkland: so that the .changes includes all the changelog entries - the merge-* scripts handle that automatically
[21:48] <Drk_Guy> neuromit, usually, sh_make takes care of that
[21:48] <Drk_Guy> *dh_make
[21:49] <mathiaz> kirkland: other than that, it was all good :)
[21:49] <neuromit> Drk_Guy, dh_make?  doesn't that just create the debian dir?
[21:49] <Drk_Guy> Guys...
[21:50] <Drk_Guy> neuromit, For example, when i ran dh_make in the gambas2 src's dir, it created a control for gambas2 and gambas-doc ;)
[21:50] <Drk_Guy> where can i take a look at the DEB sections?
[21:50] <neuromit> ahhh ok... sorry my bad,
[21:51] <neuromit> the answer was right in front of me
[21:51] <Drk_Guy> lol
[21:51] <Drk_Guy> neuromit, do you know where can i take a look at the debian sections?
[21:52] <neuromit> what do you mean by debian sections?
[21:52] <Drk_Guy> net, devel, otherosfs (wine is here)
[21:52] <neuromit>     Drk_Guy: when you select Multiple Binaries, how can you specify which files get placed with which debian package?
[21:52] <Drk_Guy> !sections
[21:53] <Drk_Guy> !section
[21:53] <Drk_Guy> neuromit, you killed me with that one, maybe snooping around with debian contents?
[21:53] <neuromit> when you say DEB sections are you talking about the categories programs are placed in in the applicatio nmenu
[21:53] <Drk_Guy> neuromit, Not really
[21:53] <Drk_Guy> neuromit, http://packages.ubuntu.com/hardy
[21:53] <Drk_Guy> But i don't know if those are right
[21:54] <neuromit> have you tried in #debian? they can pretty much answer most of my questions there...
[21:54] <neuromit> but they have a little disdain for ubuntu people
[21:55] <Drk_Guy> XD
[21:55] <slangasek> #debian is not a very good place to ask packaging questions anyway
[21:55] <Drk_Guy> peeps in debian call us noobuntu'ers
[21:55] <Drk_Guy> XDDD
[21:55] <mathiaz> Could someone set my account as a reviewer on REVU ? Trying to login says that that mathiaz doesn't exist in REVU
[21:55] <Drk_Guy> I am pretty likely to ignore it
[21:57] <norsetto> Syntux: when are you usually around on IRC (in UTC)?
[21:59] <jmarsden> norsetto: Syntux quit 10secs after you asked your question to him... it might be good to re-ask it :-)
[22:00] <neuromit> Anybody here have experience packing multiple .debs from a single source?
[22:00] <NCommander> neuromit, yes
[22:01] <neuromit> NCommander, I'm looking to learn how to do it... do you have some time to chat about it or can you recommend some good docs on the subject?
[22:01] <neuromit> The ubuntu packaging guide doesn't really cover it
[22:02] <NCommander> neuromit, sure, but this isn't a great time, I'm getting ready to go for work; once I'm at work, I can chat
[22:02] <neuromit> ok...  I probably won't be around much longer... maybe tomorrow then?
[22:02] <neuromit> I'm headed home from work in 45minutes
[22:03] <Syntux> neuromit, I don't have much experience with it myself but if you check software-properties source it should give you a glimpse
[22:03] <neuromit> Syntux, THANKS!
[22:04] <Syntux> neuromit, not at all :-)
[22:05]  * norsetto wonders what software-properties has to do with packaging multiple binaries
[22:05] <norsetto> Syntux: when are you usually around on IRC (in UTC)?
[22:06] <Syntux> norsetto, one sec
[22:07] <Syntux> norsetto, software-properties source generates multiple package, a gtk and kde http://packages.ubuntu.com/intrepid/python-software-properties
[22:08] <norsetto> Syntux: ah, you meant it as an example
[22:08] <Syntux> norsetto, sure.
[22:10] <Syntux> norsetto,  around 15 to 21 UTC.
[22:10] <neuromit> when building the multiple debs, do I simply more or less create a section in the control file for each one, then specify in each packages .install file what files are to be included in that debian package?
[22:10] <norsetto> Syntux: ok, thx
[22:10] <Syntux> norsetto, np.
[22:16]  * Syntux getting emotional with 'Grace is Gone'
[22:17]  * norsetto hands over an handkerchief to Syntux
[22:17]  * Syntux thank you norsetto , I needed it, meff meff 
[22:18] <slangasek> neuromit: that gets you much of the way there, yes
[22:20] <devfil> asac: do you know where I can find the bugs fixed by xulrunner 1.8.1.15/16?
[22:21] <emgent> evening ScottK-laptop
[22:21] <ScottK-laptop> Good evening.
[22:23] <asac> devfil: search bugzilla.mozilla.org for fixed1.8.1.15 OR fixed1.8.1.16 OR verified1.8.0.15 OR verified1.8.1.16
[22:24] <asac> (in keywords those are)
[22:25] <devfil> asac: thanks, not difficult to do xulrunner, I've finished
[22:26] <asac> devfil: test rdepends for regressions then ;)
[22:26] <asac> which is an important task for hardy-security
[22:26] <devfil> asac: how I can test them?
[22:27] <neuromit> if I want to include extra files in a deb package, (like Icons for example) how do I get them included into the deb package? Do I have to specify them in the files  or docs file?
[22:27]  * norsetto wondes why in LP the list of 2 zillion useless subscribers has been kept and the usefull source info is gone
[22:27] <ScottK-laptop> norsetto: Because the new u/i is better.  Didn't you read mpt's blog.
[22:28] <norsetto> ScottK-laptop: ah, silly me, I didn't noticed that
[22:28] <Drk_Guy> neuromit, i think the makefile governs that :=
[22:28] <Drk_Guy> ;)
[22:28] <norsetto> take or leave a d
[22:28] <neuromit> can I get other files included in the deb by specifying them in the files file?
[22:29] <norsetto> neuromit: use debian/ for that
[22:30] <neuromit> norsetto, so i've tried placing files in debian/ before only to find they aren't included in the final deb
[22:30] <jmarsden> neuromit: dh_install them to where they need to go?
[22:30] <norsetto> neuromit: well, you have to install them somehow :-)
[22:30] <neuromit> so I would call dh_install where, in postinst?
[22:31] <norsetto> neuromit: debian/rules seems a likely place to do that
[22:31] <neuromit> ok... thanks
[22:34] <emgent> ember: ping.
[22:34] <emgent> ember: can you fix bug #237348 ?
[22:37] <cody-somerville> Is anyone here good at reading boot charts?
[22:46] <tacone> apt-get source pygtksourceview works, apt-get install pygtksourceview doesn't find any package. anyone knows why ?
[22:47] <ScottK-laptop> Probably because the binary package name is different.
[22:47] <asac> devfil: 1st. look at the list of rdepends (apt-cache rdepends libxul0d or something)
[22:47] <jmarsden> tacone: Most likely the name of the source package is different from the name of the binary package(s) it creates?
[22:47] <asac> a bunch of them should be obvious to test
[22:48] <asac> browsers need some thorough testing like password management, certificate (ssl), javascript (ajax sites)
[22:48] <emgent> tacone: http://packages.ubuntu.com/hardy/python-gtksourceview2
[22:49] <asac> for non-browsers the common use-cases should be easier to guess and probably doesnt require the same amount of testing
[22:49] <tacone> emgent: nice, sorry.
[22:49] <emgent> tacone: np, you re welcome
[22:50] <devfil> asac: ok, this require time, I will do it tomorrow when I'm not sleeping :)
[22:50] <asac> devfil: sure. better safe than sorry
[22:50] <asac> ;)
[22:50] <asac> sleep well!
[22:58] <emgent> blueyed: heya
[22:58] <blueyed> Do uploads to REVU get not processed currently?
[22:59] <blueyed> Hi emgent
[23:08] <blueyed> ..it was a binary upload. (just for the record)