[00:00] <wgrant> Right.
[00:00] <wgrant> Which is still a problem.
[00:00] <ScottK-laptop> That's clearly a use restriction.
[00:00] <nxvl> need to run
[00:00] <nxvl> bbl
[00:00] <Arc> ScottK-laptop: that is akin to saying that the GPL restricts distribution
[00:00] <wgrant> It does!
[00:01] <Arc> then the GPL shouldn't comply with the DFSG
[00:01]  * cody-somerville doesn't think we need to be having a "yes, it does" "no, it doesn't" pissing match in -motu.
[00:01] <ScottK-laptop> use restriction != distribution restriction.
[00:01] <Arc> cody-somerville: I agree.
[00:01] <ScottK-laptop> cody-somerville: There is no #ubuntu-legal, so where then?
[00:01] <ScottK-laptop> Gotta run.
[00:01] <Arc> ScottK-laptop: Ubuntu has a technical council for this reason.
[00:03] <wgrant> There's little point invoking the TB without having a discussion first.
[00:07] <Arc> I guess I've gotten as much about MOTU's processes that I'm going to
[00:07] <Arc> thanks for the link guys
[00:13] <mok0> REVU seems not to consider reviews by contributors, packages are still in "new", not in "needs work"
[00:14] <RainCT> mok0: yep, that's a feature
[00:14] <mok0> RainCT: why?
[00:15] <mok0> RainCT: seems like a misfeature to me :-)
[00:16] <mok0> So we should go through and post a comment so they move to the needs-work category?
[00:18] <RainCT> mok0: rationale: contributors may be wrong, and having their comments move the package down to "needs work" may a) discourage them from commenting if they are not sure and b) annoy the uploader if someone posts a wrong comment (point c) would be that evil guys could move all uploads down, but I think/hope this wouldn't happen anyway :))
[00:18] <RainCT> mok0: the real reason though is that it isn't possible with the current design (as it's either advocate or move down)
[00:20] <RainCT> mok0: I'm not sure if the rationale is really good and there are plans to change the design so that MOTUs can post non-advocating positive comments so you even have a chance to get this changed :)
[00:22] <mok0> RainCT: It just seems there are a whole bunch of packages that actually need work, and contributors comments seem pretty sensible.
[00:23] <mok0> RainCT: I think uploaders may not have discovered that there is work to do
[00:23] <mok0> RainCT: In any case, there is an incredible amount of packages in REVU. Seems there has not been much turnaround in REVU this cycle.
[00:24] <RainCT> mok0: feel free to raise this on ubuntu-motu@ / create a blueprint for it on launchpad.net/revu / whatever
[00:24] <RainCT> (^ means the "packages don't get down to 'needs work'" point)
[00:24] <mok0> RainCT: Probably should be discussed at a MOTU meet
[00:25] <mok0> RainCT: I feel there may be quite differing opinions on this
[00:25] <RainCT> mok0: about uploaders not noticing the changes, that's being worked one (there's the atom feed now and e-mail subscriptions mail follow somewhen soon)
[00:26] <mok0> RainCT: I've posted a few "please address comments above" comments which move them to the needs-work section --- hopefully uploaders will discover that
[00:26] <RainCT> mok0: and on your last point, there were no REVU days this cycle :)
[00:26] <mok0> RainCT: yeah I noticed... any particular reason?
[00:27] <RainCT> mok0: The current REVU Coordinator hasn't much time and there were no volunteers to help him
[00:28] <RainCT> well, actually persia said there was a non-MOTU one
[00:28] <mok0> RainCT: What a shame. It is quite discouraging to the uploaders
[00:28]  * cody-somerville whats the question?
[00:29] <RainCT> mok0: indeed
[00:29] <mok0> cody-somerville: we're talking about REVU
[00:29]  * cody-somerville nods. 
[00:45] <mok0> RainCT: have a minute?
[00:46] <mok0> RainCT: never mind
[00:47] <RainCT> mok0: yes?
[00:48]  * RainCT is about to leave, so if you want something say it fast ;P
[00:55] <ssaboum_> 'night everyone
[01:51] <tgm4883_laptop> when packaging something for REVU, is it possible to get it through with a lintian warning of W: mythnettv source: patch-system-but-direct-changes-in-diff bin/mythnettv
[01:51] <tgm4883_laptop> the mentioned file isn't part of the orig.tar.gz, it was added by me
[01:51] <azeem> tgm4883_laptop: why not use the patch system?
[01:51] <azeem> hrm?
[01:52] <tgm4883_laptop> azeem, I have the same errors for setup.py and the man pages I created
[01:52] <tgm4883_laptop> If the patch system is the correct way to do it, then i'll do it that way, just seems wrong though
[01:52] <azeem> tgm4883_laptop: ok, do you know what a patch system is?
[01:52] <azeem> why wrong?
[01:52] <tgm4883_laptop> azeem, yea I'm using it for other things
[01:53] <tgm4883_laptop> azeem, seems wrong because I thought you only use a patch system when you want to fix a file from the orig.tar.gz
[01:53] <tgm4883_laptop> not when adding files necessary for packaging
[01:53] <azeem> in general, the .diff.gz should only have files under debian/ when you use a patch system
[01:54] <azeem> if you have to add files to the source tree, those should either be shipped under debian/ (if somewhat ubuntu-specific), or as a patch in the patch system when upstream specific
[01:55] <tgm4883_laptop> azeem, what about setup.py?  I believe that has to be in the root dir doesn't it?
[01:55] <azeem> yes
[01:55] <tgm4883_laptop> so I would need to make that a patch?
[01:55] <azeem> looks like it's supposed to be in upstream in the first place, no?
[01:56] <tgm4883_laptop> I guess.  I'm not that familiar with python packages, but my understanding would be that all python packages need that in the root?
[01:56] <tgm4883_laptop> and that isn't debian specific correct?
[01:56] <azeem> well
[01:57] <azeem> it's certainly not debian specific, right
[01:57] <azeem> and it's the usual way to package upstream python stuff
[01:57] <azeem> but still, other ways to distribute python stuff upstream can be thought off
[01:57] <azeem> of*
[01:58] <tgm4883_laptop> well the way it is released is a tarball that when extracted you can run from the directory it's in
[01:58] <tgm4883_laptop> not really an installation
[01:58] <azeem> euh
[01:58] <azeem> ok
[01:58] <azeem> so adding setup.py is improving on upstream
[01:58] <tgm4883_laptop> thats what i'm a fixing
[01:58] <tgm4883_laptop> yes
[01:58] <azeem> so, if there's a patch system already, it's reasonable to add setup.py as a patch
[01:59] <tgm4883_laptop> well I added the patch system, but as long as adding setup.py as a patch seems reasonable then i'll do it
[01:59] <tgm4883_laptop> I was just confused a little on what should and should not be a patch
[02:00] <RAOF> Any change outside debian/, when you're using a patch system :).
[02:01] <RAOF> So that you can send a patch upstream.  It doesn't really matter that you're adding a whole file; upstream is likely to want to see that change as a patch anyway.
[02:01] <tgm4883_laptop> RAOF, ok will do.
[02:01] <tgm4883_laptop> One more question, slightly related
[02:02] <tgm4883_laptop> this program is a command line program.  I'm adding a gui to it.  Would it be better to have the gui as a separate package?
[02:02] <azeem> hrm
[02:02] <azeem> depends on how involved "adding a gui to it" is, I guess
[02:02] <RAOF> Are you adding this GUI as an Ubuntu patch?
[02:03] <tgm4883_laptop> i've let upsteam know about the gui, and they are interested in it.  But i'm not sure that they will want to bundle the two together
[02:03] <tgm4883_laptop> RAOF, at the moment, it's a separate app
[02:03] <tgm4883_laptop> I guess the real question is
[02:03] <RAOF> With a separate source tree?
[02:03] <azeem> that sounds like something you should figure out upstream
[02:03] <tgm4883_laptop> if they do decide to bundle them together for future releases, how hard is it to kill the -gui package in the repos?
[02:04] <tgm4883_laptop> the -gui app lifts out of the command line app really easy
[02:04] <RAOF> Splitting a source package is a tradeoff between annoying the archive admins and annoying the users ;)
[02:04] <tgm4883_laptop> it just parses output from the command line app
[02:04] <tgm4883_laptop> currently it's a separate branch and everything
[02:05] <RAOF> That sounds like it wants to be an entirely separate source package, really.
[02:06] <tgm4883_laptop> IMO, they should be offered seperatly to offer less bloat.
[02:06] <tgm4883_laptop> although we're not talking very big packages
[02:07] <tgm4883_laptop> azeem, RAOF thanks for the clarifications on those issues
[02:11] <tgm4883_laptop> RAOF, azeem, I just ran into a small problem on the patch that we were just talking about regarding setup.py
[02:12] <tgm4883_laptop> In order to build, i have to apply the patch.  But if the patch is applied, I get the lintian warning when building
[02:12] <tgm4883_laptop> so i'm not really sure what to do with this catch 22
[02:13] <RAOF> tgm4883_laptop: You need to remove the file in clean:, then.  Because patches won't remove files, IIUC.
[02:16] <tgm4883_laptop> there is no clean using cdbs?
[02:16] <tgm4883_laptop> i'm probably confused here
[02:16] <RAOF> Of course there is; it's just implemented by cdbs.
[02:16] <RAOF> You can write a clean:: target, though.
[02:16] <RAOF> The double-: means "Append this on the end of the existing clean: target"
[02:17] <tgm4883_laptop> ah, and that goes in rules
[02:17]  * tgm4883_laptop is slowly getting all this packaging down
[02:18] <tgm4883_laptop> thanks RAOF, i'll look into doing that
[02:19] <azeem> tgm4883_laptop: just remove it locally
[02:19] <azeem> and let the patch system handle it
[02:20] <RAOF> azeem: Will unpatch: remove the file?
[02:20] <tgm4883_laptop> azeem, I can't remove it locally, otherwise I get an error about setup.py not being there
[02:20] <azeem> hrm
[03:07] <NCommander> ScottK, what exactly to backport testers do?
[03:09] <wgrant> soren: Ooh, you evil triblodyte bricordion nickerbook, you.
[03:10] <ajmitch> what has soren done this time?
[05:33] <dholbach> good morning
[05:38] <ScottK> NCommander: Look at the bugs in the various backports projects and then build and test that them.  For backports, the standard is builds, intalls, and runs.
[05:38] <NCommander> Ah
[05:38] <NCommander> That's easy enough ;-)
[05:38] <ScottK> NCommander: Then you mark the bug confirmed and an ubuntu-backporter will review it for approval.
[05:38] <ScottK> Yes.
[05:39] <ScottK> The trick is that if any modifications to the package are needed, then you need to have a core-dev do the upload, even for a universe package.
[05:40] <NCommander> O_o?
[05:40] <NCommander> Why's that
[05:40] <ScottK> Because source backports are discouraged.  The archive admins have a script they use for semi-automated backporting.
[05:40] <NCommander> oh I see
[05:41] <ScottK> I think they want to keep potentially disruptive backports to a minimum.
[05:41] <ScottK> Decision was made before my time, but at least there's finally one core-dev with some interest in backports.
[05:42] <NCommander> That would be you, right?
[05:42] <ScottK> yeah.
[05:43] <NCommander> what's your usual workflow for handling testing? (I think you told me once you run intrepid or hardy, so I assume you have chroot fun)
[05:43] <StevenK> steven@liquified:~% schroot -l -a | wc -l
[05:43] <StevenK> 21
[05:44]  * StevenK should clean some of them up
[05:44] <ScottK-laptop> NCommander: For backports I generally just test the ones I could run.  That means Dapper or Hardy.
[05:45] <NCommander> Bah
[05:45] <NCommander> That means downgrading for me, unless I want to run in a VM
[05:45] <ScottK-laptop> For other releases I do installability testing and such in a chroot.
[05:45] <NCommander> (I could use a chroot, but that isn't perfect)
[05:45] <ScottK-laptop> Yep.
[05:45] <StevenK> There is also a limit of what you can test in a chroot.
[05:45] <persia> StevenK: How much cleanup is possible?  I have 19 and that's only for the current and development releases.
[05:46] <ScottK-laptop> That and generally I've got decent judgement about who to believe when it comes to backports test report.
[05:46] <NCommander> BTw
[05:46] <NCommander> Any objections if I go close all the hoary bugs ;-)
[05:46] <NCommander> They seem a little out of date
[05:46] <ScottK-laptop> I did manage to break a bunch of people with a bad Flash backport a month or two ago.
[05:46] <nxvl> NCommander: ubuntu-vm-builder is your friend
[05:46] <NCommander> ubuntu-vm-builder?
[05:46] <StevenK> persia: There is 3 that need to be cleaned, and gutsy* is still in that list.
[05:46] <nxvl> NCommander: yep
[05:47] <nxvl> NCommander: it create an ubuntu VM with just one command
[05:47] <nxvl> no isos needed
[05:47] <nxvl> or configuration
[05:47] <NCommander> LVM, or what?
[05:47] <nxvl> i use kvm
[05:47] <NCommander> ScottK-laptop, I remember that, I thought that was an SRU, not a backport
[05:47] <nxvl> but it supports qemu, vmware and some other
[05:47] <nxvl> i think
[05:47] <NCommander> how hard is it to get going with kvm?
[05:47]  * nxvl checks
[05:47] <NCommander> (I've never used it before)
[05:47] <nxvl> not at all
[05:47] <nxvl> you just need the hardware
[05:47] <NCommander> If you mean VTx
[05:47] <NCommander> I got it
[05:48] <NCommander> Just need to enable the chip
[05:48] <nxvl> then you can tun ubuntu-vm-builder and it even creates a sh script to run the vm
[05:48] <NCommander> (Sony's BIOS updates like to disable it every update)
[05:48] <ScottK-laptop> NCommander: Nope.  That was a backport.  Lots of people run with backports on.
[05:48] <ScottK-laptop> It's kind of scary given how lightly they are tested.
[05:48] <NCommander> Oh fun.
[05:48] <nxvl> NCommander: https://wiki.ubuntu.com/kvm
[05:48] <StevenK> NCommander: That's what you get for buying a Sony.
[05:48] <NCommander> (you didn't answer if I could kill the horay backport bugs)
[05:48] <RAOF> NCommander: kvm is really easy as long as you're supported.
[05:48] <NCommander> Yeah well, the laptop was 600 dollars off
[05:48] <ScottK-laptop> NCommander: Sure.
[05:48] <RAOF> You may be interested in virt-manager, too.  I rather like it.
[05:49] <StevenK> NCommander: My first laptop was a Sony. Never, ever again.
[05:49] <NCommander> My previous laptop was a macbook pro
[05:49] <NCommander> Never, ever again
[05:49] <NCommander> This sony been a massive improvement
[05:49]  * StevenK hugs his X40
[05:49] <NCommander> I almost went with an Ubuntu Dell, but they were backordered for four weeks
[05:50]  * ScottK-laptop has a very nice Dell that couldn't be gotten with Ubuntu (not that I'd want it), but worked out of the box with no issues.
[05:50] <NCommander> Everything works out of the box on my sony
[05:50] <NCommander> So I'm not complaining
[05:50] <ScottK-laptop> Right, except the stuff that doesn't.
[05:51]  * StevenK sighs at his sisters laptop
[05:51] <StevenK> What were Compaq thinking, selling a laptop with XP with 224MB of RAM. It's ... dumb
[05:51] <NCommander> O_O;
[05:51] <NCommander> OW
[05:51] <NCommander> That's even low for xubuntu
[05:52] <RAOF> That's under Evolution's resident size, here :)
[05:52] <persia> It's 2% cheaper, and there's a chart somewhere that shows that sales go up when prices go down.
[05:52] <ScottK-laptop> I've got an ancient Dell with 256MB of RAM that runs Hardy Kubuntu OK as long as you only do one thing at a time.
[05:53] <NCommander> Death has come to the horay Ubuntu bugs :-)
[05:53] <StevenK> This is my sister, I think she wants MSN, Microsoft Word and 17 IE windows open all at once
[05:54]  * nxvl wants a X61
[05:54] <nxvl> but still love my T61
[05:54] <NCommander> https://bugs.edge.launchpad.net/ubp-hoary - Bugs be dead
[05:55] <StevenK> I didn't see anything compelling about the X6* over my X4
[05:55] <StevenK> Er, X40
[05:55] <ScottK-laptop> Unfortunately (if you care about such things) it doesn't help Ubuntu bug counts any.
[05:56] <NCommander> edgy is dead also, right?
[05:56] <persia> NCommander: Indeed.
[05:56] <NCommander> (I just want to clean up this bug tracker given the chance)
[05:56] <nxvl> with motu membership i get ubuntu-bug-control one too, don't i?
[05:56]  * ScottK-laptop hands NCommander a flamethrower.
[05:56] <persia> nxvl: Yes.
[05:56] <ScottK-laptop> nxvl: yes.
[05:56] <nxvl> :D
[05:56] <NCommander> I got bug-control without motu
[05:56] <NCommander> By having packages in Debian
[05:57] <nxvl> then i don't need to worry for my ubuntu-bug-control membership which is about to expire
[05:57] <nxvl> :D
[05:57] <NCommander> (I was told that I was the first to ever use that method to get bug-control group membership O_O!)
[05:57] <ScottK-laptop> nxvl: Nope.
[05:58] <persia> You can get bugcontrol for having packages in Debian?  That's interesting, but I suppose it's non-trivial to Maintain a package in Debian.
[05:58] <NCommander> Yeah
[05:58] <NCommander> They were kinda confused when I pointed to the wiki page about it
[05:58] <NCommander> It seems since bug control was established, no one ever used that
[05:58] <persia> Do they still enforce the signing of the CoC?  I know a couple people with CoC reservations who are active in Debian, actually maintain their packages for Ubuntu, and might find it helpful.
[05:59] <NCommander> Oh yeah
[05:59] <NCommander> YOu do
[05:59] <NCommander> Your only waived from the five ubuntu bug requirement with it
[05:59] <persia> OK.  That was never the problem for the specific people I'm thinking about :)
[05:59] <NCommander> Heh
[05:59] <NCommander> Yeah
[05:59] <persia> (five bugs is *easy*)
[06:00] <NCommander> Of course
[06:00] <NCommander> I think your also waived something else
[06:00] <NCommander> The test the bugcontrol guy gives you on prioritys/statusus
[06:01] <NCommander> LP seriously needs a mass bug killer
[06:01] <NCommander> Or a bug shotgun
[06:02] <persia> Very much no, just more people fixing the bugs.
[06:02] <NCommander> I don't think keeping bugs open on backports that have left support is useful ;-)
[06:02] <NCommander> I guess thats a specialized case
[06:03] <persia> Right, but that doesn't need a mass bug killer.  Closing them all is a single email after a few minutes of looking them over.
[06:03] <NCommander> You can close bugs via email?
[06:03] <NCommander> (like in Debian?)
[06:03] <persia> Yes, you can do almost anything with bugs via email.  You have to sign the mail to authenticate.
[06:04] <NCommander> so control@bugs.launchpad.net
[06:04] <NCommander> and then closes 1 2 3
[06:04] <NCommander> (etc.)
[06:04] <persia> Not precisely.
[06:04] <NCommander> I knew you could reply to bugs via email but I didn't know you could close
[06:04] <StevenK> Not control, no
[06:04] <nxvl> yeah i get ubuntu-bug-control membership before uuc and long before motuship
[06:04] <nxvl> that's why it's about to expire
[06:05] <dholbach> NCommander: https://help.launchpad.net/Bugs/EmailInterface
[06:05] <NCommander> Oh
[06:05] <NCommander> sexy
[06:06] <slangasek> nxvl: so did mok0 happen to mention to you what package this is that he was concerned about the wrong version number on?
[06:06] <NCommander> persia, er, how would you do this enmass?
[06:06] <NCommander> A lot of CCs?
[06:06] <nxvl> slangasek: not at all
[06:06] <wgrant> NCommander: That's how I do it.
[06:06] <nxvl> slangasek: just that it was a package
[06:06] <nxvl> slangasek: and the version
[06:06] <slangasek> nxvl: ohwell :)
[06:06] <nxvl> :D
[06:07] <NCommander> WHere's that GUI program for handling Launchpad bugs?
[06:07] <wgrant> NCommander: Leonov?
[06:07] <NCommander> yeah
[06:07] <NCommander> Oh, I can do bug XXX status invalid
[06:08] <slangasek> nxvl: looks like it was the torque upload to hardy-proposed
[06:08] <wgrant> You can also just write an email saying '  status invalid', and Cc it to as many bugs as your SMTP server allows.
[06:08] <nxvl> slangasek: :D
[06:08] <NCommander> I wonder how many google allows ...
[06:08] <StevenK> Hm. I think Launchpad should accept 'kthxbye' like control@bugs.d.o does
[06:09] <NCommander> control@bugs.d.o accepts kthxbye O_O?
[06:09] <nxvl> slangasek: you have quite an odd schedule, where are you based?
[06:09] <StevenK> Yes :-)
[06:09] <slangasek> nxvl: Oregon
[06:10] <nxvl> yeah, i was thinking in the US, so it is an odd work schedule
[06:10] <nxvl> :D
[06:10] <slangasek> StevenK: I'm not sure if it still does, Don has made a couple passes over the mail interface since he took over maintainership
[06:10] <slangasek> nxvl: I'm not at work right now :)
[06:10] <nxvl> slangasek: yeah sure :D
[06:11] <nxvl> if i finally got a FOSS related job i will work with an odd schedule too
[06:11] <nxvl> it's just fun
[06:11] <NCommander> Death has come to the edgy backport bugs
[06:12] <nxvl> it's like being paid for testing games
[06:12]  * NCommander downloads a freedos CD so I can fix VT on my laptop
[06:12] <nxvl> NCommander: :(
[06:12] <nxvl> poor bugs
[06:12] <nxvl> \o/
[06:14] <slangasek> nxvl: no, really, I'm not at work right now... :)  If I were at work, I should be doing things according to work priorities. :)
[06:14] <ScottK-laptop> nxvl: Congratulations.  What can you tell us about the job?
[06:14] <nxvl> :D
[06:14] <nxvl> ScottK-laptop: what job?
[06:15] <ScottK-laptop> Right.
[06:15] <nxvl> :D
[06:18] <NCommander> lol
[06:18] <NCommander> Meh, bugs-by-email seems to lag ;.;
[06:18] <ScottK-laptop> NCommander: Bug design.
[06:18] <ScottK-laptop> Bug/By
[06:18] <NCommander> It reminds me of Debian's BTS
[06:19] <nxvl> dammit i still can't upload to flickr from f-spot at home
[06:19] <nxvl> i hate my ISP provider
[06:19] <ScottK-laptop> Yes.  It's the only place their speed is ~equivalent.
[06:19] <StevenK> You hate your Internet Service Provider Provider?
[06:19] <ScottK-laptop> It's the only thing I know of that isn't faster on BTS.
[06:19] <StevenK> Is that like an ATM Machine?
[06:20]  * NCommander has a love/hate relationship with BTS
[06:20] <ScottK-laptop> Yes.  I can understand that.  My relationship with Launchpad is rather more consistent than that.
[06:20] <nxvl> StevenK: heh, it's 12:20 here :D
[06:20] <StevenK> And rather more one-sided
[06:21] <ajmitch> ScottK-laptop has a deep, abiding hatred for launchpad & all that goes with it
[06:21] <ajmitch> and loves to share that
[06:21] <ScottK-laptop> I actually prefer bugzilla.
[06:21] <StevenK> Ewww!
[06:21]  * ajmitch remembers the fun of the 1MB js that was loaded on every ubuntu bugzilla page load
[06:21] <nxvl> i felt that provider shouldn't be there
[06:23] <nxvl> well, time to sleep now
[06:23] <nxvl> read you tomorrow
[06:23] <dholbach> good night nxvl
[06:23] <nxvl> dholbach: have a nice day!
[06:23] <dholbach> thanks :)
[06:23] <persia> Yeah.  The original Malone was *much* preferable to Ubuntu bugzilla.  That said, I haven't used bugzilla since the mass import into Malone, so things may be different now.
[06:23] <NCommander> why is there 1MB of JS on the old Ubuntu bugzilla?
[06:23] <ajmitch> package list
[06:24] <ScottK-laptop> persia: I agree (about the original malone).
[06:27] <Iulian> Good morning.
[06:36] <stefanlsd> Sigh. I'm going to work. See you guys later.
[06:38] <NCommander> how can I kill every schroot on my system?
[06:40] <NCommander> brb
[06:48] <NCommander> woo
[06:48] <NCommander> now my laptop has VTx
[06:53] <Treenaks> VTx?
[06:53] <Treenaks> a laptop with a Honda motorcycle?
[06:58] <NCommander> kirkland, your ubuntu-vm javascript page is amazing
[07:16] <soren> ajmitch: I made the mistake of engaging in this discussion: http://bobbo.me.uk/?p=179
[08:33] <tacone> what's the url of that ubuntu-vm page ?
[08:37] <persia> tacone: Which ubuntu-vm page?
[08:38] <tacone> persia: I found it, nevermind. btw it was this: http://people.ubuntu.com/~kirkland/ubuntu-vm-builder.html
[08:41] <persia> tacone: You know that there is a command-line client as well, right?
[08:42] <tacone> persia: that page is a webform to generate a shell line to be used with the command line client. try to press the generate command.
[08:43] <persia> Oh.  I thought it actually generated the image.  I remembered that being talked about at some point, to support use cases where the host machine was not Ubuntu.
[08:45] <tacone> that could easily done with a little server-side scripting, just extending kirkland's work. not sure it's worth the work yet :-)
[08:49] <huats> morning fellows
[08:49] <cody-somerville> Morning
[08:59] <henrik-kabelkaos> Is there any MOTU who want to advocate CDEmu? The packages have been thoroughly fixed now.
[09:04] <henrik-kabelkaos> Besides the ubuntu brainstorm thingie listed a CD emulator as the #9 most wanted feature of all time.
[09:04] <NCommander> isn't loopback good enough?
[09:08] <henrik-kabelkaos> not really. linux can't mount CUE/BIN files and the likes.
[09:12] <Treenaks> there's a tool to convert cue/bin to .iso
[09:13] <Treenaks> also, couldn't this be done through fuse? (or is it fuse-based)
[09:21] <henrik-kabelkaos> cdemu doesn't really concern itself with filesystems but leaves that part to linux. it interpretes disc images and serves it as a virtual disc. the kernel driver is quite thin and it does most of the work in userspace. while there are a couple of interresting fuse plugins, none of them offer the quite the same functionality.
[09:29] <henrik-kabelkaos> a nice example would be that you could mount a protected MDS (alcohol 120%) image and use fuseiso to access the contents for example.
[09:45] <henrik-kabelkaos> Though in most cases HAL would catch it and mount it automagically. :)
[10:17] <gnomefreak> dpkg-buildpackage is in devscripts right?
[10:17] <StevenK> dpkg-buildpackage is in dpkg-dev
[10:17] <gnomefreak> StevenK: thanks
[10:33] <gnomefreak> maybe i had to reboot after removeing gnupg-agent
[10:34] <persia> gnomefreak: gpg signing works for you again?
[10:35] <gnomefreak> persia: i think so
[10:35] <gnomefreak> im testing another package
[10:36] <gnomefreak> persia: seems removing gnupg-agent didnt help and i shut down for the day yesterday and now it works
[10:37] <persia> gnomefreak: So just some leftovers in your session then.
[10:56] <gnomefreak> where did /etc/dput.cf go?
[10:57] <cody-somerville> Are you running Intrepid?
[10:57] <gnomefreak> cody-somerville: yep
[10:57]  * cody-somerville is on a hardy box right now so can't look.
[10:58] <Laney> I have it on Untrepid
[10:58] <Laney> Intrepid*
[10:58] <gnomefreak> i dont see anything related to dput in etc
[10:59] <gnomefreak> i have ~/dput.conf but that ws handmade for PPA
[10:59] <gnomefreak> s/ws/was
[11:01] <gnomefreak> i guess i could add it to $HOME/,dput.cf
[11:01] <persia> gnomefreak: I also have an /etc/dput.cf on intrepid.  Is the dput package installed?
[11:02] <Laney> http://pastebin.com/f546a285d is the output of dpkg -L dput
[11:02] <gnomefreak> yeah i guess since i can upload to PPA
[11:02] <gnomefreak> hmmmmm
[11:02] <gnomefreak> /etc/dput.cf
[11:02] <gnomefreak> it says i have it too
[11:03] <gnomefreak> seems i overlooked it :(
[11:04] <emgent> moin
[11:07] <jpds> moin emgent
[11:08] <didrocks> hi there :)
[11:08] <jpds> jelmer: I have merged your changes to ubuntu-dev-tools. Thanks.
[11:28] <gnomefreak> can someone please review http://revu.ubuntuwire.com/details.py?package=smartirc4net and http://revu.ubuntuwire.com/details.py?package=smuxi  the lintian warnings are most likely caused by me adding a clean option to fix FTBFS but i didnt make a patch i just changed it since it was our file not upstreams
[11:29] <gnomefreak> s/most likely/most for sure
[11:31] <geser> gnomefreak: why not use the Debian packages?
[11:31] <henrik-kabelkaos> gnomefreak: the first lintian warning is caused by diff refusing to add empty files.
[11:33] <geser> gnomefreak: see also bug 259833
[11:34] <gnomefreak> geser: thats where i got it from
[11:35] <gnomefreak> look at changelog it has debians 1 and ours
[11:36] <gnomefreak> henrik-kabelkaos: ah ok good nothing i did
[11:36] <devfil_> asac: there?
[11:37] <asac> devfil_: more or less :)
[11:37] <geser> gnomefreak: you don't need to go through REVU in that case, just file a sponsoring bug with the needed debdiff to get it build
[11:38] <asac> devfil_: how are you doing?
[11:38] <gnomefreak> geser: i thought revu was for ne packages?
[11:38] <devfil_> asac: can you take a look at the xulrunner update?
[11:38] <gnomefreak> s/ne/new
[11:38] <geser> gnomefreak: yes, for completely new packages
[11:38] <asac> devfil_: yes. i have to
[11:39] <devfil_> thanks
[11:39] <asac> devfil_: 254618 ?
[11:39] <gnomefreak> geser: ok so a debian package built for Ubuntu isnt new
[11:39] <devfil_> 205325
[11:39] <devfil_> asac: --^
[11:39] <geser> gnomefreak: we could sync the packages from debian, see that it FTBFS and upload -1ubuntu1 (no revu involved at all). So we can also skip the sync and upload -1ubuntu1 directly.
[11:39] <gnomefreak> ok
[11:40] <devfil_> asac: ops, 254618 sorry
[11:40] <gnomefreak> geser: its 2ubuntu1
[11:40] <gnomefreak> debian used the 2
[11:40] <asac> devfil_: how did you produce the the orig.tar.gz?
[11:41] <devfil_> asac: using the script on debian to remove nonfree stuff
[11:42] <geser> gnomefreak: and as the package comes from Debian, we want to keep the delta small (only needed changes) and not overhaul the whole packaging
[11:42] <asac> devfil_: and how did you get the initial bits?
[11:43] <gnomefreak> geser: i only changed changelog and rules
[11:43] <devfil_> asac: from upstream cvs, from FIREFOX_2_0_0_16_RELEASE branch
[11:43] <asac> ok
[11:43] <gnomefreak> geser: should i use the sync bug and just add debdiff and ask for sponser?
[11:44] <geser> gnomefreak: yes (if no other MOTU disagrees about the procedure)
[11:45] <gnomefreak> ok since im sure not all are around ill do it and lets see what they say
[11:49] <persia> I'd rather see a merge bug instead of a sync bug, but otherwise agree with geser that the appropriate procedure has been described.
[11:52] <asac> devfil_: please attach the debdiff of the debian/ directory
[11:53] <persia> asac: You can't actually generate that.  Do you mean diff -urN old/debian new/debian ?
[11:54] <asac> persia: debdiff | filterdiff -i*/debian/* ;)
[11:54] <persia> (well, you could generate it, but it's a mess of filterdiff calls)
[11:54] <persia> Just one?  Hmmm..  OK.
[11:54] <asac> i guess so
[11:54] <asac> (i hope so ;))
[11:55] <gnomefreak> where is the sponsorship wiki?
[11:55] <persia> I had trouble with filterdiff -i*/debian/* when I was trying to write code that would automatically generate an update package from an interdiff, but perhaps that was related to some of the test packages, and firefox isn't affected.
[11:56] <Laney> gnomefreak: https://wiki.ubuntu.com/SponsorshipProcess ?
[11:56] <persia> gnomefreak: wiki?   If you want to add something to the queue, just subscribe the sponsors to the bug in LP.
[11:58] <gnomefreak> it already was. i ust wanted to do it the right wy
[11:58] <gnomefreak> way
[11:59]  * gnomefreak thinks i should revise the version of smuxi to add -2.1ubuntu1 instead of -2ubuntu1
[12:01] <devfil_> asac: uhm, I need to upload the changelog
[12:02] <asac> he?
[12:02] <geser> gnomefreak: why -2.1ubuntu1? I see only 0.6.1-2 in the PTS page for smuxi
[12:02] <asac> devfil_: you need to debdiff the debian/ directory ;)
[12:02] <devfil_> asac: already done, but there is a new version on ubuntu 1.8.1.14+nobinonly-1ubuntu4
[12:02] <asac> dont undertstand that
[12:03] <asac> devfil_: yes. please work in the changelog entry
[12:03] <asac> that would be great
[12:03] <asac> otherwise i can to that for upload
[12:04] <asac> devfil_: please remove 89_bz419350_attachment_306066 from the package if it has been applied upstream
[12:04] <asac> devfil_: you need to debdiff the debian/ directory ;)
[12:04] <asac> oops
[12:04] <asac> :)
[12:04] <asac> mozilla bug 419350
[12:04] <asac> thats what i ment ;)
[12:04] <asac> ok
[12:04] <asac> please drop that patch
[12:06] <gnomefreak> geser: so i can leave it as -2ubuntu1?
[12:06] <devfil_> asac: is the debdiff enough or do you also want again the diff.gz?
[12:06] <asac> devfil_: both while you are at it
[12:06] <asac> ;)
[12:07] <devfil_> ok
[12:08] <geser> gnomefreak: yes
[12:08] <gnomefreak> geser: ok cool thanks
[12:16] <gnomefreak> crap
[12:17] <devfil_> asac: all done
[12:20] <gnomefreak> how do i overwrite an upload to revu? i would rather not change the version if i dont have to
[12:21] <jpds> dput -f
[12:21] <devfil_> gnomefreak: dput -f
[12:21] <gnomefreak> thanks
[12:21] <gnomefreak> much better ;)
[12:25] <asac> devfil_: wanna do the same for hardy?
[12:25] <asac> e.g. hardy-security?
[12:26] <asac> for hardy-security its important to provide the bits (as you did now) ... as well as give a list of tests you run to verify that the important rdepends still work
[12:27] <devfil_> asac: this will take a while, I will need to retest alla rdepends for hardy
[12:28] <asac> devfil_: well. you can do some initial tests, then i can give those packages to the security team, while you finish the rest of the tests
[12:28] <asac> to finally give green light ;)
[12:29] <devfil_> asac: ok
[12:35] <asac> devfil_: upload finished. please watch whether it fails to build or something
[12:35] <asac> ;)
[12:35] <devfil_> asac: sure
[12:36] <asac> thanks
[12:36] <asac> devfil_: firefox-2 in hardy needs a bump too ;)
[12:37] <devfil_> asac: from ? to ?
[12:37] <asac> devfil_: from whatever is in hardy to 2.0.0.16
[12:38] <devfil_> asac: hardy-security already have 2.0.0.16
[12:38] <asac> oh
[12:38] <asac> then i was wrong and it was seamonkey ;)
[12:39] <devfil_> seamonkey is 1.1.9
[12:39] <asac> yeah ... 1.1.11 is what is in intrepid
[12:39] <asac> (1.1.10 was never release afaik)
[12:40] <devfil_> ah ok
[12:40] <devfil_> asac: is the changelog for hardy-security the same of a SRU or is normal?
[12:40] <asac> devfil_: what do you mean?
[12:41] <stefanlsd> Is there a list of requirements somewhere for applying for UUC?
[12:41] <devfil_> asac: the revision number of the package
[12:41] <asac> devfil_: you mean the changelog target? thats "hardy-security"
[12:41] <devfil_> no, the revision number
[12:41] <devfil_> 0ubuntu1?
[12:41] <Laney> stefanlsd: https://wiki.ubuntu.com/UbuntuDevelopers#ContribDev
[12:42] <asac> devfil_: its the intrepid revision appended by ~8.04.1
[12:42] <devfil_> asac: ok
[12:42] <asac> 0ubuntu1~8.04.1
[12:45] <dholbach> Who of you could imagine running a session at Ubuntu Developer Week?
[12:45] <dholbach> I just thought we could repeat one of the sessions we had as part of MOTU School
[12:46] <nxvl> dholbach: i really want to, but if i'm still in my current job this week i can't
[12:46] <nxvl> :(
[12:46] <nxvl> dholbach: sorry
[12:47] <dholbach> Ubuntu Developer Week is next week! :)
[12:47] <dholbach> nxvl: if you're too busy, I understand - no problem
[12:47] <nxvl> yes i know
[12:47] <nxvl> not busy, just no irc access
[12:47] <nxvl> :(
[12:47] <emgent> heya daniel :)
[12:48] <dholbach> hi Emanuele
[12:49] <nxvl> i'm waiting for a new job offer and contract
[12:49] <nxvl> which should arrive today or tomorrow
[12:49] <dholbach> all the best with that!
[12:50] <nxvl> thank you
[12:50] <nxvl> if it arrives i will really probably able to run a session
[12:52] <huats> dholbach: didrocks and I are planning to give one
[12:52] <dholbach> huats: add it to the schedule!
[12:53] <dholbach> :)
[12:53] <huats> we need to talk about it together (today)
[12:53] <dholbach> alright
[12:53] <dholbach> thanks
[12:53] <huats> and I'll add it then
[12:53] <huats> no pb
[12:54] <huats> does anyone knows when norsetto is coming back from holidays ?
[12:56] <persia> End of the month, isn't it (next week)?
[12:56] <huats> ok
[12:56] <huats> thanks persia :)
[12:56] <persia> huats: I'm not entirely sure, mind you.
[12:56] <huats> ok
[12:56] <huats> :)
[12:57] <huats> I was looking for him since he has started to review a package of mine...
[12:57] <huats> so if anyone wants to give a shot :)
[12:57] <huats> please do :)
[12:57] <huats> http://revu.ubuntuwire.com/details.py?package=tktreectrl
[13:02] <jelmer> jpds, thanks!
[13:06] <apachelogger> persia: hey, how to get into ubuntu-universe-sponsors?
[13:07] <persia> apachelogger: Be a MOTU and ask.  I'll add you now.
[13:08] <apachelogger> persia: cool, thanks :)
[13:08] <persia> apachelogger: LP matches IRC?
[13:08] <apachelogger> yes
[13:09] <persia> apachelogger: Done.
[13:10] <apachelogger> thank you
[14:17] <RainCT> can someone tell me what http://paste.ubuntu.com/40419/plain/ means? :P
[14:18] <StevenK> RainCT: It means nautilus is buggy
[14:19] <nxvl> yep
[14:19] <nxvl> echo $url > launchpad
[14:19] <persia> It's a stacktrace and memap.
[14:20] <RainCT> That happens each time I select a file/directory, since some months. I guess that's because I have some libraries from Intrepid, but I don't know which has the problem
[14:20] <persia> Without the nautilus dbgsym it's not easy to follow, but probably related to a change in the contents of a directory that nautilus had open (which may not be in any of the current windows)
[14:21] <RainCT> (may it be because of a library? because else I'm completely lost on what the problem could be..)
[14:22] <persia> It could well be a mismatch between the version of nautilus and the version of a given library, but it looks like nautilus is passing an invalid object to libgobject, which makes me thing the problem is in nautilus (or an extension), rather than in gobject, gio, glib, or libc
[14:23] <persia> That said, the bug could well be because nautilus requested an object that wasn't given from some random source, and assumed it to exist because it didn't check, and then passed it on, so the bug in nautilus may be invisible in the case where the libraries match exactly.
[14:27] <TheMuso> 5~/c
[14:28] <RainCT> Uhm.. Why do I have libc6 from Intrepid? XD
[14:30] <RainCT> and why is Synaptic too stupid to downgrade it? :P
[14:31] <RainCT> well nevermind, I can continue living without nautilus
[14:34] <persia> RainCT: Why do you have any intrepid libs on a hardy system?  Surely it's better to either use hardy or intrepid, no?
[14:34] <bddebian> Heya gang
[14:35] <Laney> hi bddebian
[14:35] <bddebian> Hello Laney
[14:36] <directhex> persia, everyone tries apt pinning once, then learns their lesson
[14:36] <persia> directhex: For an unstable/testing system, it makes some sense.  For the way that Ubuntu does development, this is not nearly so true.
[14:37] <RainCT> persia: I can't have my complete system on Intrepid because my connection is too slow to keep up with all the updates, so I just take those applications that I like the most from Intrepid :P
[14:37] <persia> RainCT: Ah, right.  You are prepetually bandwidth starved :(
[14:37] <huats> I am not very familiar with python-support, so if someone is, I'd like to ask a few questions
[14:38] <persia> Just ask.  Many of us will have done something with python support, although few of us are experts.
[14:38] <huats> :)
[14:39] <huats> well there something I am missing, but I don't know what...
[14:39] <huats> that is teh real problem
[14:40] <huats> I have my packaging which seems to right
[14:40] <huats> everything seems to be placed good
[14:40] <huats> but
[14:40] <huats> when I installed it
[14:40] <Laney> !enter | huats
[14:40] <Laney> :P
[14:40] <Iulian> Indeed
[14:41]  * Iulian rolls his eyes
[14:41] <huats> nothing goes in /var/lib/python-support
[14:41] <huats> thanks Laney ;)
[14:41] <persia> huats: Are you referencing python-support anywhere in your packaging?
[14:41] <huats> I am
[14:42] <huats> I can paste my debian/rules file
[14:42] <huats> http://paste.ubuntu.com/40428/
[14:43] <huats> persia: and I have noticed that when I install the package the python-support triggers are actionned
[14:46] <RainCT> what is -i for?
[14:46] <persia> RainCT: It's typically passed to dh_foo for arch-independent packages.
[14:48] <RainCT> persia: ah, thx
[14:48] <huats> thanks persia for answering :)
[14:52] <huats> any idea ?
[14:52] <huats> james_w: you are the one who directed me toward that :) no idea neither ?
[14:52] <huats> ;)
[14:53] <RainCT> huats: where are the .py files installed?
[14:53] <persia> huats: Generally it mostly works.  Do you see all the files you expect from dpkg --contents?  Is something missing?
[14:54] <RainCT> ember: I'm looking at hamster-applet :)
[14:54] <huats> RainCT: it provides a .so
[14:54] <waylandbill> I submitted a patch addressing bug 260741 as a comment attachment. Is there anything else I need to do for it to be considered for inclusion? This is the first bug I've fixed.
[14:55] <ember> thanks RainCT
[14:55] <huats> persia: I don't think there is something missing
[14:55] <RainCT> huats: Ah. But .so files don't need byte-compilation, so there's noting to do for dh_pysupport, or?
[14:57] <RainCT> ember: uh.. what's about bug #216675?
[14:57] <huats> RainCT:  there is a specific part of /usr/share/doc/python-support/README.gz on .so files
[14:57] <huats> that is why I am asking :)
[14:57] <Laney> waylandbill: You should update the changelog (using dch -i)
[14:57] <RainCT> huats: ah, I see..
[14:59] <james_w> huats:    ** Note that even if a package only ships extensions, it MUST still ship the /usr/share/python-support/foo directory.    **
[14:59] <Laney> waylandbill: Make sure to include (LP: #260471) in the description of your change so that the bug is closed automatically
[14:59] <james_w> (from the README)
[14:59] <huats> oh
[14:59] <huats> let me check
[14:59] <ember> RainCT:about  what ITP or Andrew's ?
[15:00] <RainCT> ember: Andrew's
[15:00] <waylandbill> Laney: okay. After I do, I submit the resulting patch as another comment?
[15:00] <huats> james_w: I am shipping it
[15:00] <Laney> waylandbill: Yes, and you can delete the old one if you want
[15:01] <huats> james_w: but almost empty
[15:01] <huats> I'll check if something is missing
[15:01] <james_w> huats: it can be empty I think
[15:01] <ember> About Andrew's i really didn't know, when i opened the bug on LP i search for hamster-applet
[15:01] <james_w> huats: is the latest version on REVU?
[15:01] <ember> but i can ping him about it
[15:02] <huats> james_w: not yet
[15:03] <Laney> waylandbill: Also, you can produce the patch for uploading with the "debdiff" command, invoked as "debdiff old.dsc new.dsc > output.debdiff"
[15:06] <RainCT> ember: Well, doesn't seem like he wanted to get his one into Ubuntu. Is there some reason why you need to add the MAINTAINERS file? :P
[15:08] <ember> RainCT: file got missing from the tarball in this release
[15:15] <RainCT> ember: Ah. The package looks good, I'm test building it now :)
[15:17] <waylandbill> Laney: okay. I updated the changelog and uploaded the output from debdiff.
[15:18] <Laney> waylandbill: The version should be 2.2, but other than that it's great
[15:18] <ember> RainCT: andrew's just reply it, it's ok
[15:19] <ssaboum> hi everyone, i wanted to know if there was a standard procedure for packaging something that already has a .deb for debian ?
[15:19] <persia> james_w: dholbach: Are you still having trouble filling sessions for DeveloperWeek?
[15:20] <dholbach> persia: I'm still hassling a bunch of people
[15:20] <dholbach> persia: if you have suggestions, let me know :)
[15:21] <waylandbill> Laney: cool. I wasn't sure if the version needed to be changed or if it would've just had ubuntu1 appended.
[15:21] <persia> dholbach: If you run short, I can do another reading apport bugs session at either 16:00 on Thursday or 17:00 on Friday, but it's an awkward time for me, so please consider this a backup if you're having trouble, rather than an open offer.
[15:22] <dholbach> persia: we could still move the 20:00 UTC slot to 15:00 UTC :)
[15:22] <RainCT> ember: Good work, advocating... Should I upload it? :)
[15:22] <Hobbsee> ah, developer week, where european developers are targetted again!
[15:23] <ember> RainCT: thanks
[15:23] <persia> 15:00 is better for me, but I've meetings that sometimes run over that are supposed to end at 15:00 on Tuesday, Wednesday, and Thursday, so not that much better (and it's late here anyway).
[15:23] <dholbach> I understand
[15:23] <ember> RainCT: yes you should heh :p
[15:24] <persia> Making it later is probably better, to have a chance to catch Americans (or Australians early in the morning)
[15:24] <persia> Hobbsee: What time is 21:00 UTC there?
[15:24] <Hobbsee> persia: 7am, usually
[15:24] <Hobbsee> but daylight savings might have began / ended since then.
[15:25] <persia> Hmm.  So 6 or 7.  Probably too early then, and 16:00 is about as late as I'm willing to stay up.
[15:25] <Hobbsee> yep, 7.
[15:25] <Hobbsee> http://www.timeanddate.com/worldclock/fixedtime.html?day=25&month=8&year=2008&hour=21&min=0&sec=0&p1=0
[15:26] <persia> dholbach: No point moving it then, unless you get feedback from someone in the New World.
[15:26] <RainCT> ember: done
[15:26] <dholbach> alright
[15:26] <ember> RainCT: thanks!
[15:26] <persia> (not that any of them are here now :) )
[15:36] <Juli__> persia: hi:) don't you forget about netbeans packages? I'm afraid it will be too late soon:(
[15:37] <persia> Juli__: I didn't forget at all, I've just been very busy.
[15:38] <Juli__> yes I understand... but after freeze we'll not be able to upload new packages, right?
[15:39] <Juli__> and netbeans 6.1 won't be in Intrepid
[15:41] <persia> Juli__: At least for the parts I can do by myself, they will be in intrepid, if I need to not sleep on Wednesday.  For the new packages, you will also need a second advocate.  You might seek one here.
[15:43] <Juli__> I'm embarrassing to ask you in such conditions but I don't know what else I can do...
[15:43] <Juli__> Thank you in advance
[15:44] <persia> Juli__: No, bugging me is the right thing to do.  You still also need someone else (as I can't add a new package on my own).
[15:45] <Juli__> yes I see... I'll try to find. Actually we've canceled forked resolver, so there are just 2 new packages for now
[15:45] <persia> Nice work!  I thought that could be done.
[15:46] <Juli__> Actually it is still a temporary workaround but for netbeans 6.5 I hope we'll do better
[15:49] <Juli__> LucidFox: I see you has reviewed libjna-java on REVU... may be you can help with a second advocate, please?
[15:49] <persia> Juli__: You've already fixed everything from the last review?
[15:50] <Juli__> yes
[15:51] <Juli__> excepting build-dep on sun jdk
[15:52] <Juli__> Currently build dependency is default-jdk
[15:52] <Juli__> I hope it is enough
[15:52] <huats> james_w: i have put the new version in revu... I still don't see the problem...
[15:53] <persia> Juli__: That ought use OpenJDK where available, which ought be enough.
[15:53] <huats> james_w: (it will be there in 5 minutes)
[15:55] <james_w> huats, can you provide the link again please?
[15:55] <Juli__> persia: so, everything is fixed after LucidFox's review. + libnb-platform-java is left
[15:56] <huats> james_w: sure http://revu.ubuntuwire.com/details.py?package=pywebkitgtk
[15:57] <james_w> thanks
[15:57] <huats> james_w: you are the one to be thanked :)
[15:58] <huats> (james_w the new version is not visible yet)
[15:58] <persia> Juli__: You're in pretty good shape then, on libjna.  libnb-platform-java is trickier, and you'll want someone else.  Worst case, maybe it can be considered a new upstream of the old package (just with a slightly different name).
[16:00] <ssaboum> persia can you tell me where i can find the namings of the sections for apt repositories, you know (games, contrib, ...)
[16:00] <ssaboum> ?? please
[16:01] <persia> ssaboum: Google for debian control files and their fields
[16:01] <persia> Scroll down about one third of the page
[16:01] <ssaboum> ok thx
[16:01] <persia> click the link to the sections under the explanation for Section
[16:02] <Juli__> persia: actually it is a new upstream of the old package ... if it is possible to proceed under this assumption it would be great
[16:02] <persia> Oh, and you're feeling lucky
[16:02] <persia> Juli__: Better if you can find a second advocate, as this means less begging the archive admins :)
[16:04] <Juli__> hmmm... I don't know how it is usually happens.. it is my first experience...
[16:05] <Juli__> Can anyone here take a look on the package on REVU, please?:))
[16:05] <persia> Juli__: You'll probably get more looks if you include the URL to the packages that need review.
[16:06] <persia> (the REVU url)
[16:06] <Juli__> persia: ok, thanks!
[16:06] <Juli__> http://revu.ubuntuwire.com/details.py?package=libnb-platform-java
[16:07] <Juli__> and http://revu.ubuntuwire.com/details.py?package=libjna-java
[16:08] <Juli__> actually libnb-platform-java package is the new upstream version for existing libnb-platform7-java package
[16:09] <Juli__> so it would  be sad to have no ability to upload it because of new name only
[16:17]  * directhex prepares another main merge. yay, main
[16:19] <Laney> boo main, yay universe
[16:20] <directhex> it's one of those lovely source packages that makes lots of binary packages, of which only 1 is in main
[16:20] <directhex> so i need to mess about with merging instead of syncing, purely to get rid of universe build-deps
[16:22] <persia> directhex: Is it needed in main?  Does something seed it?  Perhaps it can be pulled out.
[16:25] <directhex> persia, it looks like it was forced in for slightly bizarre reasons, looking at the dep chain
[16:26] <persia> directhex: The split packages are often like that.  Reading the MainInclusionReport can be helpful.
[16:29] <directhex> persia, essentially, monodoc-base is a build-dep for pretty much every mono lib or pluginabble app, as it's needed to generate documentation. so either ubuntu removes all docs (making it worthless for developers) and adding significantly to developer overheads who can no longer sync anything, or ubuntu dumps all mono apps from main (which would make some people happy, but involve ripping out things like tomboy and f-spot), or ubunt
[16:29] <directhex> u sucks it up & puts monodoc-base in main
[16:29] <geser> Juli__: libjna-java commented
[16:29] <directhex> that's my reading of it
[16:29] <persia> directhex: Nothing to be done except the merge then.
[16:30] <geser> Juli__: btw. is it normal that the Debian packaging has only a copyright 2007 but the actual packaging was done 2008?
[16:30]  * persia thinks that it ought be 2007,2008
[16:31] <Juli__> geser: Thank you for comments! hm, yes it seems to be a typo from copy-paste. I'll correct.
[16:33] <directhex> persia, monodoc needs a merge instead of a sync in order to keep xsp (asp.net web server) out - since the monodoc source package has a possible http front-end
[16:34] <persia> directhex: Right.
[16:35] <medo_> I'm having trouble packaging a tcl/tk software any ideas of how I should start with it? I have searched the web and the wiki with no clues at all
[16:36] <medo_> I am thinking of copying all the needed files into /usr/share and have a script in /usr/bin to run it
[16:36] <persia> medo_: You might want to look at another tcl/tk package as an example.  It's not such a popular widget toolkit these days, so documentation is sparse.
[16:36] <huats> medo_: not sure I can really help
[16:36] <medo_> is this the correct approach
[16:36] <huats> but I am currently packaging a tcl/tk stuff
[16:36] <huats> I have one ack already
[16:36] <persia> If I remember correctly, it's mostly text files, so you'd end up with heavy use of /usr/share/$(package)/, but I may be mistaken.
[16:37] <huats> so the package should not be that bad :)
[16:37] <persia> huats: You are an expert: of course you can help :)
[16:37] <huats> http://revu.ubuntuwire.com/details.py?package=tktreectrl
[16:37] <medo_> yeah it is mainly text files no binary at all
[16:37] <huats> persia: thanks :)
[16:37] <huats> persia: btw if you want to kill some time, you can review it :)
[16:37] <medo_> huats: I actually need that package
[16:37] <persia> huats: See above :)
[16:38] <medo_> so if u can please keep me updated on its status
[16:38] <huats> medo_: sure
[16:38] <huats> medo_: what do you want to package ?
[16:38] <medo_> coccinella
[16:38] <huats> oh
[16:38] <medo_> an IM software
[16:38] <huats> that is the reason why I have packaged tktreectrl :)
[16:39] <huats> nice choice :)
[16:39] <medo_> thanks for the help :)
[16:39] <huats> but you'll figure out that you need lots more than tktreectrl :)
[16:40] <medo_> hope fully it is easy stuff this is my first package
[16:40] <medo_> :)
[16:40] <medo_> and it is giving me hard time
[16:40] <huats> :)
[16:40] <huats> you are packaging coccinella ?
[16:41] <huats> what bout the other dependencies ?
[16:42] <medo_> I will have to work on those first I believe but I have just started looking at it
[16:42] <medo_> i asked because i didn't know how to start
[16:43] <huats> ok
[16:43] <huats> so you might start working on the various dependencies that coccinella has
[16:44] <huats> which means the various binaries it relies on
[16:44] <Juli__> geser: About license in upstream: I'll write a letter to the jna source's owners and ask them to add a license into upstream zip.
[16:44] <medo_> ok so they have to be in there own packages as well right?
[16:45] <huats> medo_: yes, it is better
[16:45] <Juli__> geser: But if it will not be easy, may be it is possible to add it somehow through get-orig-source?
[16:46] <medo_> huats: ok then I will start working on the deps first and see where I can get. I might come back for help
[16:46] <huats> medo_: exactly
[16:47] <huats> and if you need an example of tk packaging have a look at my package
[16:50] <geser> Juli__: good question, I don't know. It depends if the archive admins accept it or not.
[17:07] <Juli__> geser: hm... the problem also that it is freeze soon... I really need this package in Intrepid. I'll write them today. Hope they will accept but not sure.
[17:11] <geser> sebner: Hi, did you manage to build smuxi? I tried it but I ended in an endless loop.
[18:03] <sebner> geser: dpkg-deb: building package `smuxi' in `../smuxi_0.6.1-2_all.deb'.
[18:04] <sebner> geser: and all the other stuff
[18:06] <geser> hmm
[18:09] <geser> sebner: did you build on i386 or on amd64?
[18:09] <sebner> geser: i386
[18:10] <geser> then it's probably just a i386/amd64 issue
[18:11] <sebner> geser: seems so :\
[18:12] <geser> sebner: ACKed so it hopefully makes it before FF
[18:12] <sebner> geser: thanks and I swear, I never never ever will file a sync request without testbuilding it. Such a disaster O_o
[18:13] <geser> sebner: I thought you usually test-build before filing a sync request?
[18:13] <huats> if anyone want to have a look at http://revu.ubuntuwire.com/details.py?package=tktreectrl
[18:13] <ScottK-laptop> sebner: You really should.
[18:14] <huats> i have an ACK already, and the second one is almost there BUT he is on holidays :(
[18:14] <sebner> geser: Yes, but this time, really only this time I didn't cause I talked to Mirco Bauer and quickly filed the sync request without further thinking :(
[18:14] <sebner> ScottK-laptop: :(
[18:36] <henrik-kabelkaos> when you're finished with a package. got reviews etc. do you set the packaging bug to fix committed and clear assigned to? and is sponsor something i need?
[18:37] <Laney> It's done automatically by LP if you put (LP: #xxxx) in the changlog entry
[18:38] <henrik-kabelkaos> i see. does ubuntu-universe sponsors need to be subscribed to the bug?
[18:41] <persia> henrik-kabelkaos: The second advocate for a package will upload it.  No need to subscribe the sponsors queue unless someone advocates, forgets to upload, and goes on holiday (or similar situation), and even then, you can usually just ask here.
[18:41] <persia> ("I got two advocates for foo, but it doesn't appear to have been uploaded: it's not in the NEW queue, and it's not in the archives.  Could someone have a look at http://revu.ubuntu...
[18:42] <henrik-kabelkaos> thanks.
[19:04] <Elbrus> Hi, I am trying to package a new program called winff
[19:05] <Elbrus> Unfortunately I am not able to compile in intrepid or hardy because of bug #260464
[19:06] <Elbrus> it is written in freepascal (Lazarus)
[19:07] <Elbrus> how to procede? Compiling and patching fpc myself before packaging?
[19:07] <Elbrus> what would the upload be worth?
[19:10] <RainCT> REVU will now show a warning on the details.py page if a non-native package hasn't got a debian/watch file or get-orig-source rule, and if it's a native package show a notice noting that.
[19:10] <Elbrus> By the way, my (Debian) package is available at http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=winff
[19:11] <Elbrus> Could I upload to revu? (The package does not compile)...
[19:13] <RainCT> Hi Elbrus. You can upload it, but Feature Freeze is about to start so it's probably already to late to get it into Intrepid. And if your getting it into Debian there's no need to go through REVU, too.
[19:17] <Elbrus> RainCT: ok, so if the bug gets fixed before the FF it can be included, else it has to wait?
[19:19] <RainCT> Elbrus: you would also need to get your package advocated by two MOTUs on time
[19:19] <Elbrus> ah, by the way.. there can be a slight difference between the Debian and Ubuntu version because the package depends on ffmpeg and that is more extensive in Ubuntu.
[19:19] <Elbrus> RainCT: exactly..
[19:20] <Elbrus> RainCT: That's why I wonder if it would be useful to upload just yet.
[20:00] <Elbrus> My package is now on http://revu.ubuntuwire.com/details.py?package=winff but again, waiting for bug #260464 to be fixed, unless somebody can help me work around that.
[20:04] <Laney> Elbrus: Sadly it's unlikely to make it in for Intrepid now :(
[20:06] <huats> I haven't found anywhere the answer : in python packaging .pc file and .defs should be provided in a separate -dev package or not (which means in the library package)
[20:07] <Elbrus> Layey: I'll just have to wait than, the same problem at Debian (also freeze) and nowbody wants to comment
[20:07] <Elbrus> Layey: it is my first package, I would appreciate some comments in the mean time if possible
[20:18] <henrik-kabelkaos> huats: if you have a -dev package that's where it should go. if not, you're probably fine as long as you're packaging the .pc file together with the python extension module(s).
[20:37] <ssaboum> hi everyone, how is it going
[20:39] <henrik-kabelkaos> ssaboum: i suppose i should say konbanwa?
[20:39] <ssaboum> konbanwa henrik :-)
[20:39] <ssaboum> thanks for your review i'm working on it
[20:39] <ssaboum> btw i can't figure out how to deal with the debian/watch file and the fact that the source code is on googlecode
[20:40] <ssaboum> so uscan try to access the directory but googlecode only permit to access the files (if you know their names obviously)
[20:41] <ssaboum> henrik-kabelkaos:any idea ?
[20:58]  * Laney eats warp10's wallpaper
[21:09] <asomething> ssaboum: this works in a package I maintain that has googlecode upstream: "http://code.google.com/p/<projectname>/ http://<projectname>.googlecode.com/files/<packagename>-(.*)\.tar\.gz"
[21:10] <asomething> file-browser-applet is my package
[21:17] <ssaboum> thank you asomething i'll try
[21:17] <dcordero> hi
[21:17] <ssaboum> hi :-)
[21:18] <dcordero> if i have a bug that make me change a lot of things in the package... should i write (LP: #number_bug) in each line of changelog?
[21:18] <kirkland> tacone: NCommander: agreed on your comments about ubuntu-vm server page...  very basic, but grand aspirations
[21:18] <kirkland> tacone: NCommander: If I had enough CPUs/Disk/Bandwidth, I'd gladly generate the images myself ;-)
[21:19] <NCommander> heh, I already shot myself in the foot with vm-builder
[21:19]  * kirkland is on holiday, forgive the long latency
[21:19] <NCommander> Now I need o figure out how to unshoot myself
[21:23] <jcastro> emgent: your security list got created right? But I think kees picked a different name?
[21:26] <jpds> jcastro: Appears to still be on RT #2938.
[21:26] <jcastro> jpds: yep, I am trying to confirm
[21:27] <jcastro> jpds: ng and I were talking about it with kees and I don't remember what the outcome was.
[21:27] <jpds> jcastro: I must of missed that, sorry.
[21:28] <jcastro> no worries, I'm just trying to find out if we just said "let's ask kees" or if there was any action on the ticket
[21:30] <kees> jcastro: I had sent you email with a suggested list name, that's all I've done wrt to that RT
[21:30] <jcastro> yeah that's what I thought.
[21:38] <jcastro> jpds: ah, Ng and I are full of fail, the discussion was over im, irc, and mail instead of in the ticket.
[21:41] <jpds> jcastro: Nevermind :)
[21:54] <Elbrus> dcordero: I think it does not hurt you and helps to be clear, but once is enough for the bugreport I think
[21:56] <huats> scottK are you around ?
[21:56] <ScottK> Sort of.
[21:56] <huats> :)
[21:56] <huats> how are you ?
[21:56] <ScottK> A bit overwhelmed with things currently.
[22:07] <dcordero> Elbrus, thanks, finally i have grouped all the changes, with various lines inside for each change begining with +
[22:07] <dcordero> and with (LP #number) only in the title of the group
[22:07] <dcordero> i think it is elegant
[22:09] <Elbrus> dcordero: sounds like it
[22:09] <Elbrus> dcordero: I am no expert, but I believe I saw it similar elsewhere.
[22:38] <jpds> Laney: re: bug #259599 - do you have a source package I can dget and upload somewhere?
[22:39] <jpds> Laney: I'm off for the night; but I'll upload your package as soon as I get back, semantik was at the buttom of my TODO.
[22:39] <Laney> jpds: I can upload the orig and dsc if you'd like
[22:40] <Laney> I've just been doing some pre-ff package updates
[23:03] <ssaboum> 'night everyone
[23:23] <RAOF> We don't have the ability to do per-arch rebulids, do we?
[23:24] <soren> For failed builds?
[23:24] <soren> Or rebuilds to build against new dependencies?
[23:24] <RAOF> For 'needs to build against new dependencies'.
[23:24] <wgrant> No, we cannot do binNMUs.
[23:25] <RAOF> bug #181068 suggests that python-gnome2-extras could use a rebuild on PPC, in Hardy.
[23:25] <wgrant> Upload a build1
[23:25] <nxvl> i've had some problems with packages not building from source due a dependency change
[23:26] <wgrant> That's a different kind of dependency change.
[23:27] <RAOF> wgrant: Yeah.  I was just wondering if it was easy to upload a build1 that only rebuilt on PPC.
[23:27] <RAOF> Since that would be the minimum possible fix.
[23:28] <wgrant> No, unfortunately.
[23:28] <nxvl> RAOF: you can't rebuild it on LP?
[23:29] <RAOF> nxvl: I don't have that sort of power :)
[23:29] <wgrant> Nobody does.
[23:29] <RAOF> Also, that wouldn't solve it, because it _needs_ a version bump so people get the fixed rebuilt package.
[23:30]  * nxvl tries
[23:30] <nxvl> wgrant: i can rebuild my FTB packages
[23:32] <RAOF> So, who has a PPC ubuntu install they'd like to rebuild gnome-python-extras on and test that Miro loads? :)
[23:33] <nxvl> nope i can't
[23:33] <nxvl> but you can ask an archive admin to rebuild it
[23:45] <wgrant> nxvl: It didn't FTBFS...
[23:45] <wgrant> nxvl: And archive admins won't do that.
[23:45] <wgrant> We can do it just as easily as they can.
[23:46] <huats> does any one can point me out an URL explaining when to add stuffs to python:Depends ? like python-gtk2 by instance
[23:46] <huats> I have foudn a french page but it si not explained why
[23:47] <RAOF> huats: python:Depends contains an appropriate dependency on the _python_ package; it doesn't do magical dependency resolution.
[23:48] <RAOF> Much as it would be nice for that to happen (and techinically possible.  kinda)
[23:48] <huats> RAOF: but shlibs:Depends is doing it that kind of magic right ?
[23:49] <RAOF> Yes.
[23:49] <huats> that I were I get the confusion :)
[23:49] <leleobhz> someone can help-me understand debian NMU?
[23:49] <RAOF> But that's because it's both easier to do, and because the tools do it.
[23:49] <huats> ok
[23:49] <huats> thanks
[23:49] <wgrant> leleobhz: Debian might be able to help better...
[23:50] <huats> so python:Depends is 'only' for the python interpreter ?
[23:50] <leleobhz> wgrant: hmmm... but isnt the same policy for ubuntu too?
[23:50] <RAOF> huats: Yes.
[23:50] <huats> RAOF: ok
[23:50] <RAOF> leleobhz: No, because we don't have maintaners.
[23:50] <huats> :)
[23:50] <huats> thanks for that explanation :)
[23:50] <leleobhz> RAOF: no?
[23:50]  * leleobhz more confused than ever
[23:51] <RAOF> Debian has the concept of the maintainer lock.  Only the maintainer(s) should upload the package.  We don't; anyone is free to upload.
[23:51] <leleobhz> RAOF: hmmm
[23:52] <leleobhz> RAOF: have some good place on freenode to ask or i need to go to oftc?
[23:52] <asac> leleobhz: go oftc ;)
[23:53] <leleobhz> :]
[23:53] <leleobhz> another
[23:53] <leleobhz> someone here pasted a link for "things to do for ubuntu"
[23:53] <leleobhz> someone can help-me to find a job?
[23:53]  * leleobhz dont understand that page and ... i want package! :p
[23:56] <Laney> leleobhz: Maybe you should apply for a mentor
[23:56] <leleobhz> Laney: what?
[23:59] <Laney> leleobhz: Somebody who can guide you through the processes :)
[23:59] <Laney> anyway, I'm off to bed. nn
[23:59] <leleobhz> Laney: im interested in. how can i proceed