[00:00] <mok0> jsplice: python based
[00:00] <jsplice> mok0, ah ok
[00:01] <mok0> !bzr
[00:01] <mok0> jsplice: bzr is tighly integrated with launchpad
[00:02] <jsplice> mok0, cool...man, so much to learn
[00:03] <mok0> jsplice: yeah, I think we've covered enough
[00:03] <mok0> :-)
[00:03] <jsplice> i'm going to start digging around that wiki link and in LP just to start to get a feel for all of this
[00:05] <mok0> jsplice: great. I am going off to bed now
[00:05] <jsplice> mok0, ok thanks again for the help
[00:06] <mok0> jsplice: good luck, see you later
[00:06] <jsplice> mok0, good night
[01:32] <crimsun> heh, I hope this isn't a watch file ;)  http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/ekiga/lucid/annotate/head:/debian/watch
[02:26] <rockstar> Hey folks.  I'm trying to update a karmic package to a new released version for lucid.  Should I just create a new orig.tar.gz and then move the debian/ folder into the unpacked version, or is there a better way?
[02:26] <StevenK> rockstar: That way works
[02:26] <StevenK> Along with updating the changelog
[02:27] <rockstar> StevenK, yea, that's kinda obligatory.  :)
[02:33] <micahg> uupdate?
[02:37] <bernhard> hi im currently doing a deb file and im quite lost with the rules file
[02:37] <bernhard> i need to isntall my python program to /opt/ and chmod it
[02:38] <bernhard> how do i do this?
[04:08] <mr_steve> Hi all, I've been doing a fair bit of Ubuntu packaging for my own purposes, and I'd really like to start contributing to Ubuntu.
[04:10] <mr_steve> I've been reading as many of the docs about it as I can find, but I still could use a little guidance
[04:10] <ScottK> This is the right place.
[04:11] <ScottK> !ask
[04:13] <mr_steve> Well lets see here. I've packaged up cnetworkmanager, a CLI tool for controlling NetworkManager. Should I assign the needs-packaging bug to myself while I work on it, or should only current devs and MOTUs do that?
[04:16] <mr_steve> And also, when I create a package for review, should the Maintainer: be set to me, or to MOTU Developers?
[04:19] <RAOF> MOTU developers.  revu will complain otherwise.
[04:19] <RAOF> You're welcome to assign the needs-packaging bug to yourself.
[04:20] <mr_steve> RAOF: Thanks. I see now that lintian scolds me as well, if Maintainer: isn't an @ubuntu address
[04:23] <mr_steve> What about XSBC-Orginal-Maintainer? dpkg-source warns that it isn't set. Should it be?
[04:24] <mr_steve> oh nevermind, I found it in one of the docs
[05:18] <mr_steve> Alrighty, I just made my first ever upload to REVU for some reviewers to rip to shreds for me :)
[05:19] <mr_steve> http://revu.ubuntuwire.com/p/cnetworkmanager
[11:53] <shilbert> Hi all, does anyone know how often Lucid is synced from Debian testing ?
[11:54] <directhex> shilbert, whenever an archive admin is bored & feels like running it
[11:54] <directhex> until DIF anyway
[12:06] <ejat> hi .. can someone help me with this http://bit.ly/9QswSj
[12:40] <directhex> ejat, fix debian/patches/1003_redirect_to_STDERR.patch ?
[12:40] <ejat> directhex: done ..
[12:40] <ejat> i forgot to remove the patch .. since i replace with latest
[12:41] <ejat> thanks for ya help directhex
[13:52] <_stink_> hey folks - i'm trying to package a sort of obscure X driver - it's not been packaged for anything Debian based yet, just RPM.  i have the source tarball and all, and i've done dh_make to get an example debian/ dir, but the rules file is killing me.  anyone have a good reference that clearly explains how to write a rules files from scratch?  the results on google have not helped me much.
[13:53] <slytherin> _stink_: have you checked the packaging guide on wiki.ubuntu.com?
[13:55] <_stink_> slytherin: yes.  the example rules file on there is very different from the one dh_make gave me
[13:55] <_stink_> doh, he left
[13:59] <_stink_> what i mostly don't get is how to turn the already working ./configure; make; make install stuff from upstream into debian build stuff that works.
[14:03] <_stink_> ok, got it to work this time.  the call to make in that example makefile ignores CFLAGS that the ./configure script made, and just uses the ones declared in the rules file.
[14:04] <_stink_> but i still think there is very little useful documentation on how to write one of these things.
[14:06] <e-jat> anyone can help with this http://paste.ubuntu.com/368887/
[15:20] <wrapster> I looked at my /etc/sudoers file and see 2 entries for ROOT... like so http://pastie.org/809427
[15:20] <wrapster> can anyone tell me how to fix this issue?
[15:20] <wrapster> seems weird!
[15:20] <wrapster> and also what does so many ALL=(ALL) ALL mean
[15:23] <mr_steve> wrapster: that does look a little strange... but maybe ask in the #ubuntu channel? #ubuntu-motu isn't a support channel...
[15:23] <wrapster> ok thanks.
[17:37] <cyberix> How do you get stuff from Debian Unstable to Lucid?
[17:37] <cyberix> Should I write a freeze exception?
[17:38] <ari-tczew> cyberix, FFe is starting in 18th Feb
[17:38] <ari-tczew> s/in/on
[17:39] <ari-tczew> now you can use requestsync
[17:40] <ari-tczew> of course if you are sure that there is not delta
[17:40] <ari-tczew> if delta is exist, please do merge
[17:48] <ScottK>  ... if the delta is still needed.
[17:57] <abogani> Hi MOTUers! Sorry for my very bad English! I'm repackaging  original tarball (for remove not dfsg compliant binary files) and thus implementing an get-orig-source into debian/rules which get code directly from SVN.  In get-orig-source when I remove those binary files could I reassemble also layout of the source files or not?
[18:10] <abogani> Otherwise Anyone know a good example of get-orig-source implementation to take as example?
[18:13] <persia> abogani: Where's upstream?
[18:15] <abogani> persia: www.arduino.cc
[18:16] <hyperair> abogani: take a look at codelite's get-orig-source.
[18:17] <persia> abogani: You want a three-argument http call
[18:18] <persia> abogani: Something like "http://arduino.cc/en/Main/Software arduino-([\d]+).tgz http://files.arduino.cc/downloads/arduino-([\d]+)-linux.tgz"
[18:18] <persia> With that in the watch file, you may not need a get-orig-source
[18:18] <sebner> hyperair: do you already know where, how etc you will apply?
[18:19] <hyperair> sebner: DMB, it seems?
[18:19] <persia> DMB is likely best-current-compromise.
[18:19] <abogani> persia: It don't contain source code...
[18:20] <hyperair> persia: when's the next meeting?
[18:20] <persia> abogani: Ah, so you need something that pulls from Google Code and creates a tarball?
[18:20] <persia> hyperair: The 16th, I believe.
[18:21] <abogani> persia: Yes because upstream neither release a source package nor will do it in the future.
[18:22] <persia> Annoying that.
[18:23] <abogani> I already talk with and they deny to release a clean source package: perhaps you give me a link where it is written "clean source package is a mandatory" they could change opinion...
[18:23] <persia> abogani: Try using svn instead of cvs with the cvs example at https://wiki.ubuntu.com/PackagingGuide/Complete#Changing%20the%20Original%20Tarball
[18:24] <abogani> persia: Ok but could I change source code layout of the repacked orig tarball?
[18:25] <persia> Sure.  It's just a makefile.  You can do anything you like.  Just document it.
[18:25] <abogani> persia: Ok thanks!
[18:31] <hyperair> hmmm 16th.. third day of chinese new year.
[18:31] <hyperair> what a hectic period.
[18:31] <hyperair> maybe i should just wait for the next one
[18:36] <zooko> Whoo! Time to upgrade my development (virtual) machine at work to Lucid. :-)
[18:39] <geser> persia: did you any further changes to lp:ubuntu-dev-tools before uploading? the changelog in trunk has still UNRELEASED and 0.92 isn't tagged yet
[18:39] <persia> What?
[18:40]  * persia fiddles
[18:43] <persia> geser: I *think* it's sorted now.  Please let me know if I did something wrong.
[18:44] <geser> persia: thanks, looks good now
[18:46] <blueyed> Is there a way to see where apport has sent the crash report to (launchpad +filebug url)? I've closed the tab that popped up by accident and it's not in the undo tabs list.
[18:46] <Laney> hmm
[18:46] <Laney> it's hard to remember to push bzr branches when packaging with them
[18:46]  * Laney needs to self-fix
[18:47] <persia> blueyed: On your LP page, get the list of bugs you filed, and sort by newest first.  It ought be near the top.
[18:47] <blueyed> persia: I've not filed it yet..
[18:48] <blueyed> (and it's not in the list)
[18:48] <persia> In that case, LP doesn't have the attachments.  Use apport-bug to generate a bug from your .crash file.
[18:48] <zooko> Oh man that was the most disappointing upgrade attempt ever.
[18:49] <zooko> "update-manager-text" on Lucid segfaulted. :-)
[18:49] <persia> Cool!  CAn you get a stacktrace?  It should never do that.
[18:50] <blueyed> persia: well, it has the report.. apport has just uploaded the 200+MB, but a special URL is required to access/report it. Will use apport-bug to resend it. Thanks.
[18:50] <blueyed> s/report/data/
[18:50] <zooko> persia: let's see, maybe just "ulimit -c unlimited"?
[18:51] <persia> blueyed: Maybe check your browser history?  I thought that LP tossed the attachments from an incomplete report.
[18:51] <zooko> Darn it didn't segfault this time.
[18:51] <zooko> Although the text is unreadable because it is cyan-on-cyan or something...
[18:51] <persia> zooko: heh.  You've discovered the "Hey, nobody's looking, so we can crash!" bug :)
[18:53] <blueyed> persia: a new firefox tab popped up (where the +filebug url would have been displayed), but I deleted it by accident (pressed "d" on it in vimperator). so tab is gone. Normally you could restore the tab using "u" (or ctrl-shift-T), but it's not registered. also not in :history.
[18:53] <blueyed> persia: it will hopefully toss the attachments, but after a given timeout only.
[18:54] <randomaction> Hey guys, we have a sponsoring request to fix a watch file (already forwarded to Debian), and I'm tempted to close it as wontfix/too insignificant. Would that be OK?
[18:55] <Laney> Is the package currently in sync?
[18:55] <persia> randomaction: If the Debian package is orphaned, it's worth sponsoring to shut up UEHS.  If the package has a maintainer in Debian, there's no point.
[18:55] <zooko> persia: ah, it segfaults when click space bar, which is for selecting something, although I can't see what I'm selecting. :-)
[18:55] <persia> randomaction: Extra points for getting a sponsored QA Upload in Debian for it and syncing as your preferred way to sponsor :)
[18:55] <zooko> But no core fie.
[18:55] <zooko> I'm just to change the contents of my /etc/apt/sources.list and run sudo apt-get dist-upgrade. :-)
[18:56] <zooko> That's always worked before...
[18:56] <persia> zooko: Try enabling apport, which can sometimes get more info.  Might be the sort of thing that gets a Python traceback, rather than a core file.
[18:57] <zooko> Well, it is a segfault...
[18:57] <zooko> But sure I'll give that a try real quick.
[18:58] <randomaction> http://packages.qa.debian.org/s/stage.html : patched in Ubuntu, has maintainer, is in a sorry state
[18:59] <rhpot1991> persia: mind if I subscribe you to bug 516762?
[18:59] <persia> rhpot1991: Yes.
[18:59] <rhpot1991> persia: ok sorry then
[19:00] <persia> No problem :)  I check the sponsors queue when I'm not doing anything else, but it's usually faster to let someone else upload.
[19:00] <persia> Subscribing me may cause others to think I'm paying attention, and delay sponsoring.
[19:01] <randomaction> rhpot1991: superm1 would be your best point of contact
[19:01] <persia> randomaction: That is in sorry state.
[19:01] <persia> Why?  For a sponsor request, just put it in the sponsors queue.
[19:01] <randomaction> because he's the maintainer
[19:01] <rhpot1991> persia: PM'd you something
[19:02] <persia> randomaction: We don't have maintainers in Ubuntu.
[19:03] <randomaction> persia: hmm, so it's ok to sponsor stuff for Ubuntu-specific packages where a MOTU is listed in Maintainer field?
[19:03] <rhpot1991> persia: do I need to do something to put it into the sponsors queue or just subscribe uus?
[19:04] <persia> randomaction: Absolutely.
[19:04] <persia> rhpot1991: subscribing UUS *is* putting it in the sponsors queue.
[19:05] <rhpot1991> persia: good, just wanted to make sure I was ready to go
[19:05] <randomaction> rhpot1991: you did everything right, this bug is in the queue
[19:06] <randomaction> persia: OK, I was misunderstanding that part of package maintenance :)
[19:06] <persia> randomaction: Note that we maintain stuff collaboratively, so play nice and so on, but yeah, there's no maintainers here.
[19:07] <randomaction> playing nice it what I'm trying to do :)
[19:07] <randomaction> s/it/is/
[19:07] <RainCT> Package insight has been removed from Debian, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566579 - Do we still want it in Ubuntu?
[19:09] <persia> If we don't have variance, it ought get autoremoved (similar to sync)
[19:09] <RainCT> persia: Ubuntu has a patch to fix a FTBFS with some new gcc
[19:10] <persia> Ah.  In that case, it needs an explicit removal request.
[19:10] <Laney> I got spanked before for uploading something in Ubuntu that wasn't team maintained
[19:10] <Laney> Maintainer: was a person
[19:10] <persia> Laney: Please let me know if that happens again.  We *don't* have maintainers in Ubuntu.
[19:10] <randomaction> persia: how do I organize a QA upload in debian? Upload to m.d.o + RFS to debian-qa@?
[19:10] <persia> Anyone who believes we do needs to be reminded (perhaps by the TB)
[19:10] <RainCT> Laney: Really? I do that all the time
[19:11] <Laney> RainCT: I never even thought to check
[19:11] <persia> randomaction: And you need some special entries in the changelog.  I'd recommend asking for guidance in #debian-qa@OFTC
[19:11] <RainCT> persia: Yeah, just wanted to ensure nobody objects to the removal
[19:12] <persia> RainCT: That's what bugs are for :)  If nobody is subscribed, we guess nobody cares :)
[19:12] <persia> But is this libinsight3?
[19:12] <randomaction> RainCT: I like that reason for removal :)
[19:13] <RainCT> persia: No. insight - Graphical debugger based on GDB
[19:14] <persia> OK.  Just wanted to make sure, because there's lots of stuff in the FTBFS list that has rbuilddeps on something like that.
[19:14] <RainCT> You mean insighttoolkit
[19:14] <persia> Yeah, that's the bit that I conflated.  Sorry.
[19:17] <randomaction> Laney: was it you who rebuilt agda on armel? It timed out again.
[19:17] <micahg> does the UBuntu installed sync new packges from testing as well?
[19:17] <micahg> *installetr
[19:19] <RainCT> ok, filed bug #517206
[19:19] <RainCT> persia: By the way, nice work on pbuilder-dist :).
[19:27] <RainCT> Is anyone coming to FOSDEM?
[19:28] <StevenK> RainCT: Argh!
[19:29] <StevenK> RainCT: You don't need to file bugs about removals that happened in Debian. We will notice.
[19:29] <geser> StevenK: oh, removals are now "synced" too?
[19:29] <RainCT> StevenK: Oh OK. So you check all removals (even when Ubuntu has diverged)?
[19:29] <StevenK> geser: And they have been for a long time
[19:30] <persia> StevenK: I thought that removal syncs didn't happen when we had divergence.  If that isn't the current behaviour, can we make it so?
[19:31] <geser> StevenK: is that a seperate task like syncing new packages or part from an other task?
[19:32] <persia> I'm fairly sure it's a separate task (it has a separate script)
[19:35] <StevenK> Right.
[20:10] <superm1> randomaction,  normally i sponsor stuff that's ~mythbuntu related, but rhpot1991 is looking to get more visibility in the ubuntu community as a whole for when he applies to ~mythbuntu-dev or possibly ~motu
[20:12] <randomaction> ok, sorry for the noise
[20:13] <persia> No, it's good.  Lots of times we forget that we're all working together, and it's nice to have reminders.
[20:20] <MTecknology> somebody told me that if you fill up a drive linux won't be able to boot anymore
[20:20] <MTecknology> I know services will fail to start but I was pretty sure it would still boot.....
[20:21] <persia> Depends on how you do it, but it ought boot.
[20:21] <MTecknology> I decided I'm going to try :P
[20:21] <persia> If you have no space in /tmp, and you aren't using a tmpfs, you might have issues starting X, gdm, etc.
[20:21] <persia> heh.
[20:22] <rhpot1991> mysql normally gets unhappy about that as well, dies and marks tables as crashed
[20:23] <persia> I thought mysql was more sensitive to /var and /var/tmp
[20:23] <MTecknology> I have a 2.5GB virtual disk to install Ubuntu 9.10 Desktop on a VM; I figure after installing it that should be plenty small enough to fill up quickly
[20:23] <MTecknology> persia: default partitioning, nothing fancy
[20:24] <MTecknology> I converted two families to Ubuntu in the last two days :)
[20:25] <MTecknology> They seemed to take to it very well. ~1hr training and away I went; the guarantee of not getting spyware and the mass collection of games for the littles ones was a big seller. they hated the multiple desktop part though - too much for them to take in
[20:26] <rhpot1991> persia: if your /var is on the same partition as / it wont matter, not sure if separating them helps
[20:27] <MTecknology> It probably helps some, I usually separate /, /home, /swap, /vm
[20:27] <persia> rhpot1991: heh.  True.  Separating /tmp out prevents users from filling /var, which I find handy.
[20:30] <ScottK> MTecknology: Consider Firefox's security record before making too many guarantees about spyware.
[20:31] <ScottK> https://bugzilla.mozilla.org/show_bug.cgi?id=476766 for extra scary fun.
[20:32] <zooko> Yeah sudo apt-get dist-upgrade seems to have worked.
[20:35] <MTecknology> ScottK: the chances of them getting hit on an up to date ubuntu are low enough that I felt safe saying that
[20:36] <MTecknology> ScottK: firefox seems to be the weakest link in all of linux land.... except security auditing tools which seem to be riddled with holes
[20:37] <ScottK> Look at recent webkit vulnerabilities.  It's not just webkit.
[20:37]  * persia notes that uninstalling firefox works just fine
[20:37] <ScottK> webkit/firefox
[20:38] <MTecknology> !info nitrogen
[20:41] <MTecknology> I want to do some code work with this guy and then make a package for it... lal is designed to be VERY VERY light weight but this new feature would hinder that; so we want to use a make flag to either have that option or not; how would I handle something like that from the package standpoint? I would probably want lal and lalcal. I'd really like to have the same code base and only a single package
[20:43] <persia> MTecknology: That's the sort of thing that ./configure usually does.  Dunno if you want all of autotools, but you can then do things like --enable-foo and --disable-foo.
[20:46] <MTecknology> persia: maybe have the makefile create two binaries lal and lal-cal then install those?
[20:46] <persia> Could do that also.
[20:46] <MTecknology> there is no configure script in there
[20:47] <MTecknology> I wouldn't even know where to start on making one :P - which means if you think that's a good idea then I can do that
[21:16] <LLStarks> hey, will docky ever get a package release for lucid?
[23:50] <Laney> it doesn't even have an upstream release yet
[23:52] <RAOF> Upstream would very much like to get it in Lucid, but they're cutting it fine.
[23:52] <directhex> yeah, just a tad
[23:53] <directhex> my FF priority is moonlight
[23:53] <RAOF> It'll be easy enough to whip up a package once they give me (or ask me to cut) a tarball.
[23:53] <RAOF> Then I just need to convince someone to review it!
[23:54] <Laney> Mirco Bauer™
[23:55] <directhex> The Meebster(c)
[23:55] <RAOF> Like Jack Bauwer, only more awesome.
[23:55] <RAOF> Or whoever that 24 guy is.