[00:03] <james_w> I'm unable to build anything in a jaunty pbuilder as aptitude won't install due to libapt, is anyone else seeing this?
[00:03] <ScottK> Did wxpython get fixed?  2.8 was fubar yesterday.
[00:04] <ScottK> Working here.
[00:04] <ScottK> james_w: You can switch your pbuilder to use the classic pbuilbersatisfydepends that uses apt.  Maybe it's better.
[00:07] <geser> james_w: is that inside the pbuilder or in the host system?
[00:07] <james_w> inside pbuilder
[00:08] <geser> I've update my jaunty pbuilder today without problems
[00:09] <geser> and there was no apt or aptitude upload in the last few weeks
[00:12] <james_w> idiot!
[00:12] <james_w> I was trying to build with a mix of jaunty and experimental
[00:19] <goshawk> hi, about armel support, i can see that the jaunty alpha-5 has "ixp4xx" and "versatile" versions, where can i find infos about the differencies?
[00:28] <ScottK> goshawk: I think there is an #ubuntu-armel channel (or something like that)
[00:28] <goshawk> ScottK: yep it's #ubuntu-arm i'm already there now
[00:28] <goshawk> thx
[00:29] <ScottK> OK.  That's the best place to ask.
[00:29] <ScottK> Mostly it's Europeans, so it's kind of not the best time.
[00:33] <cyberix> I think this bug has a wrong status https://bugs.launchpad.net/ubuntu/+bug/248231
[00:33] <cyberix> The package is already in Jaunty repositories
[00:33] <cyberix> What should the correct status be?
[00:34] <cyberix> s/sh/w/
[00:39] <ScottK> If it's already in Jaunty it should be Fix Released.
[00:48] <cyberix> ScottK: Should I leave the assignment in place or set it to nobody?
[00:48] <ScottK> It doesn't much matter.  Just change the fix released
[00:50] <cyberix> done
[00:51] <cyberix> thanks for help
[01:01] <Laibsch> Hi
[01:02] <Laibsch> Looking for help in getting python-4suite-xml to actually compile against python 2.6
[01:02] <Laibsch> http://launchpadlibrarian.net/23448421/buildlog_ubuntu-jaunty-amd64.python-4suite_1.0.2-7ubuntu1_FAILEDTOBUILD.txt.gz
[01:02] <Laibsch> is the build failure
[01:05] <geser> have fun figuring out why the build didn't produce for 2.5 hours no output at all
[01:06] <Laibsch> yeah
[01:06] <Laibsch> I have no clue about that either
[01:06] <james_w> does it work on your machine?
[01:06] <james_w> or is this the memory eating one?
[01:06] <Laibsch> Compiling, you mean?
[01:06] <james_w> yeah
[01:07] <geser> james_w: that's the same spot where I aborted my pbuilder build as it took already 1 GB swap plus my 5 GB RAM
[01:08] <james_w> urgh
[01:08] <james_w> does a rebuild with python 2.5 still work?
[01:09] <geser> the python2.5 part works (see in the beginning of the log)
[01:10] <ajmitch> geser: that's a rather large amount of memory to use for a build
[01:12] <Laibsch> I'm sorry, my local machine would be underpowered I assume
[01:13] <Laibsch> not enough RAM and not enough CPU, I guess
[01:13] <geser> ajmitch: it might be less as my pbuilder uses a tmpfs, but usually I don't need any swap to build a package
[01:13] <ajmitch> I think any machine would be underpowered if it keeps on chomping through memory like that
[01:18] <Laibsch> What can we do?
[01:19] <Laibsch> Is there any channel like #debian-python for ubuntu?
[01:19]  * Laibsch is not aware of such a thing
[01:28] <ScottK> Laibsch: There is not.
[01:28] <ScottK> Laibsch: What I would do is look upstream for a new release or in their VCS for changes for 2.6 compatibility.
[02:11] <Laibsch> ScottK: Do you think that would go  in despite the freeze?
[02:11] <Laibsch> Jaunty has the latest Debian version IIRC
[02:11] <ScottK> Laibsch: A patch to fix it definitely.  A new version maybe.  Certainly if it's the only way to fix it.
[02:19] <Laibsch> I'm chatting with the devs
[02:19] <Laibsch> It looks really bad
[02:19] <Laibsch> python 2.6 is a known problem
[02:19] <Laibsch> Last release was more than 2 years ago
[02:19] <Laibsch> I'm not sure there is gonna be a solution from upstream
[02:21] <ScottK> Not good.
[02:21] <ScottK> But you're going about it the right way.
[02:24] <etank> evening everyone
[02:25] <etank> i am trying to go through the motu recipes and i am stuck on the watch file one
[02:25] <etank> everything worked find until the 'debuild -S -sa' step
[02:25] <etank> here is the output that i got http://dpaste.com/6618/
[02:26] <etank> what could i have missed?
[02:29] <Laibsch> etank: I don't think that is watch-file related
[02:29] <etank> i dont think it is either
[02:29] <etank> it is just where i got stuck going through the recipe
[02:30] <Laibsch> Does the previous version build?
[02:30] <etank> https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch  this is what im going through
[02:30] <Laibsch> with none of your changes?
[02:30] <etank> Laibsch: it seems to be running
[02:30]  * Laibsch wonders how come everyone seems to have a @ubuntu.com address these days
[02:30] <Laibsch> seems or is?
[02:31] <etank> ran but failed at the end because of gpg issues
[02:36]  * etank wonders if it is because the watch file isn't in the new dir
[03:02] <dtchen_> Laibsch: not everyone =)
[03:07] <Laibsch> dtchen_: ??
[03:08] <Laibsch> not everyone?  I don't see the connection to anything I wrote
[03:08] <Laibsch> What are you referring to?
[03:10] <dtchen_> Laibsch: 18:30  * Laibsch wonders how come everyone seems to have a @ubuntu.com address these days
[03:13] <Laibsch> dtchen_: man "seems" ;-)
[03:15]  * JontheEchidna uses @kubuntu.org, but has @ubuntu.com too :D
[03:23]  * Laibsch just opened bug 338079 on the dire state of python-4suite and python 2.6
[03:25]  * ScottK has both and uses neither
[03:31] <savvas> what happened with bug 335741 ? should I subscribe sponsors for my patch proposal or is it about to be decided?
[03:34]  * ScottK isn't about to decide anything.
[03:42] <savvas> ScottK: do you happen to know if I package a new version for mobile-broadband-provider-info from svn this weekend, is it possible to make it for jaunty? it's basically an xml file with service provider information
[03:42] <ScottK> It's in Main, so no idea.  I'd ask pitti during European work hours tomorrow.
[03:43] <savvas> ok, thanks :)
[04:15] <cody-somerville> Is there a member of the MOTU Council around?
[04:27] <nhandler> cody-somerville: Most are probably sleeping. Although nixternal should still be up.
[04:42] <Kamping_Kaiser> Is there a person/channel i can ask in regarding python-apt breakage?
[04:49] <nixternal> cody-somerville: what's up?
[04:53] <ScottK> Kamping_Kaiser: I'd ask mvo tomorrow.
[05:16] <Kamping_Kaiser> ScottK, thanks.
[05:17] <Kamping_Kaiser> as python-apt is a package in Ubuntu, does that mean there will be a bzr branch of it somewhere on LP?
[05:18] <ScottK> Since it's in Main, usually.
[05:18] <ScottK> If you apt-get source the package it'll tell you in debian/control
[05:18] <Kamping_Kaiser> ok, thanks. I'll go and have a look.
[05:24] <Kamping_Kaiser> heh. the XS-Vcs-Bzr: 404s. guess i'm waiting for mvo tomorrow ;)
[05:53] <Toadstool> hello everybody
[05:58] <fabrice_sp_> Hello Toadstool
[05:58] <Toadstool> hi fabrice_sp_
[08:56] <directhex> is there a template for an RM request bug?
[09:18] <slytherin> can anyone please tell me who maintains seeds for mobile-meta package?
[10:32] <huats> geser: are you around ?
[11:33] <AnAnt> Regarding debian bug #411851 , I tried the pm-utils hook script but it didn't work, does Ubuntu something else other than pm-utils for suspend/resume ?
[11:34] <geser> huats: yes
[11:37] <eMerzh> If someone want to review my package at http://revu.ubuntuwire.com/details.py?package=sqliteman ... thanks
[11:40] <huats> geser: give me 1h I am about to eat :)
[11:40] <directhex> eMerzh, VERY minor style point, missing comma in deps in debian/control
[11:40] <eMerzh> erf...ok:)
[11:41] <directhex> eMerzh, and i don't think including a README.source is usual unless you're altering an upstream tarball
[11:42] <directhex> eMerzh, otherwise, i like it. it's well-packaged IMHO.
[11:43] <eMerzh> ok...thanks
[11:43] <directhex> no, i can't advocate, i'm not a DD
[11:45] <directhex> ehm, MOTU
[11:45] <directhex> whoops
[11:46] <eMerzh> hehe....i 'll corret this and ask again  :)
[11:47] <AnAnt> where can I ask about suspend/resume & pm-utils ?
[11:59] <slytherin> directhex: eMerzh: reame.source is needed if you are using a patch system.
[11:59] <directhex> slytherin, srsly? is that in the policy someplace?
[12:01] <slytherin> directhex: https://wiki.ubuntu.com/README.sourceHowTo
[12:01] <slytherin> directhex: policy 3.8.0
[12:04] <directhex> slytherin, at least it's only a recommended, so i won't be shot
[12:07] <ScottK> It's required by 3.8.0.
[12:09] <c_korn> the build of scilab-5.1 fails. but it succeeds in a ppa. the error is about empty translation files. can someone help me what to do? http://launchpadlibrarian.net/23510243/buildlog_ubuntu-jaunty-lpia.scilab_5.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[12:12] <geser> c_korn: that's easy: remove the empty po file in the clean target: [ -s modules/scipad/locales/fr_FR/scipad.po ] || rm -f modules/scipad/locales/fr_FR/scipad.po
[12:12] <geser> and so on for the others
[12:18] <c_korn> geser: is "install/scilab::" the right target  to put that in?
[12:21] <geser> c_korn: that should work too, as long as the empty po files are removed before the deb gets build
[12:23] <slytherin> geser: if the files need to be removed before the deb gets built then install isn't the right target, is it?
[12:25] <geser> slytherin: the debs gets build in the binary* target which usually depend on the build and install targets
[12:25] <slytherin> Oh, I always thought it gets in install target. :-(
[12:26] <geser> the install target only runs "make install" (or any equivalent) so the files are copied to the place from where the deb gets build
[12:26] <c_korn> slytherin may be right, because there are other commands in the install target already and I do not see them executed in the build log. so they are executed after the error I think
[12:27] <c_korn> http://pastebin.com/d15e454e9
[12:28] <c_korn> this is the debian/rules file
[12:32] <geser> pkgstriptranslations is called almost at the end of the build, only a few calls follow it, so it must be an other reason why the install/scilab target isn't called
[12:35] <sistpoty|work> hi folks
[12:36] <directhex> hello sistpoty|work
[12:36] <sistpoty|work> hi directhex
[12:39] <geser> c_korn: install/scilab isn't run on lpia as scilab is arch:all
[12:39] <geser> if you look at the i386 build log you will find the calls from install/scilab there
[12:40] <c_korn> geser: ah, yes. I see
[12:40] <c_korn> so what is the right target?
[12:43] <geser> c_korn: I'd propose the clean target
[12:45] <c_korn> geser: hm, but won't that be in the diff.gz afterwards because clean is called when debuild -S -sa? maybe I should write patches to delete those files?
[12:50] <geser> c_korn: delete files don't appear in the .diff.gz
[12:51] <c_korn> hm, ok
[12:51] <eMerzh> thanks for the note slytherin ... i'll just correct the comma then...
[12:52] <eMerzh> slytherin, or directhex  in fact... where must i put the comma? :s
[12:52] <directhex> eMerzh, you were missing a space, you have foo,bar somewhere
[12:53] <eMerzh> directhex, ok ... sorry :D
[12:54] <c_korn> geser: I will reupload scilab to revu. some has to upload it to jaunty again
[12:56] <geser> c_korn: open a sponsoring bug with the debdiff between jaunty and the new version
[13:00] <c_korn> geser: can I attach the debdiff in bug 272264 and reopen it?
[13:02] <geser> sure, that works too (but don't forget to close it again in your changelog entry)
[13:03] <c_korn> geser: like that? "  * debian/rules: Remove empty translation files (Closes LP: #272264)"
[13:06] <geser> c_korn: yes
[13:10] <DktrKranz> c_korn: commented for scilab
[13:11] <c_korn> DktrKranz: thanks. I used sbuild for testing in clean chroot
[13:12] <DktrKranz> having that package inside a chroot helps to triage those kinds of FTBFS
[13:12] <DktrKranz> (or to avoid them as well)
[13:15] <huats> geser: I am back
[13:16] <geser> huats: and I'm still here :)
[13:17] <huats> geser: great
[13:17] <huats> geser: so I am finally taking care of python-webkit....
[13:17] <huats> sorry for the delay
[13:17] <huats> for the python2.6 migration
[13:17] <geser> huats: no problem, it's not like python-webkit is the last package to transition
[13:17] <huats> is it ?
[13:18] <huats> do you have some link for this transition ?
[13:18] <huats> so that I can have a look at what needs to be done...
[13:18] <huats> or is it a simple rebuild stuff ?
[13:19] <geser> huats: https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027528.html
[13:19] <huats> geser: ok
[13:19] <huats> I am having a look
[13:19] <huats> and I let you know
[13:20] <geser> huats: over 200 (binary) packages still have a dependency on python < 2.6
[13:20] <huats> ok
[13:20] <huats> i though you were ironic :)
[13:21] <DktrKranz> huats: the best way I approach at them is using edos-debcheck, so you could have a look at it for targeted packages
[13:21] <huats> ok
[13:21] <DktrKranz> don't remember the exact command, but man pages is cool
[13:22] <huats> ok
[13:25] <directhex> DktrKranz, did you see my awesome collection of sync bugs for mono 2.0 lib transitioning? mostly done, already! :o (!)
[13:29] <DktrKranz> directhex: not yet, I've been mostly offline this week, but I noticed uploads in Debian. Thanks :)
[13:29] <Laney> RAWR
[13:29] <Laney> super efficient transitioners r us
[13:29] <directhex> good arvo, Laney!
[13:29] <Laney> yo
[13:29] <Laney> I upgraded my work pc to Jaunty and am now xless
[13:30] <directhex> Laney, this is my fear about upgrading my new home pc :|
[13:30] <directhex> Laney, i hope i can get sound out of intrepid
[13:30] <DktrKranz> Laney: it's not ubuntu fault, it's because of global warming
[13:30] <Laney> yeah, but if it's new then you have nothing to lose (except time)
[13:30] <Laney> DktrKranz: You mean I've gone back in time to before we had a problem?
[13:30]  * Laney is so 1970s about now
[13:31] <DktrKranz> Laney: you have the best GUI available, a TTY
[13:31] <c_korn> geser: I attached the debdiff and set the bug status to incomplete: https://bugs.launchpad.net/ubuntu/jaunty/+source/scilab/+bug/272264/comments/43
[13:31] <DktrKranz> :)
[13:31] <Laney> getdeb?!?!
[13:31] <directhex> is there a way to check the parameters on a module?
[13:32] <DktrKranz> c_korn: you have to use another revision for that
[13:32] <c_korn> oh, so it is 0ubuntu2 ?
[13:34] <DktrKranz> yes
[13:34] <DktrKranz> you can't reuse an already uploaded revision
[13:34] <DktrKranz> you can, if you like REJECT mails :)
[13:35] <directhex> i don't like those :<
[13:35] <savvas> decompyle package is removed
[13:35] <savvas> ..and awaiting the response for bmpx (bug 337659)
[13:35] <DktrKranz> directhex: especially Debian side ;)
[13:36] <directhex> DktrKranz, 2 months i've been waiting on moon i NEW. 2 months!!!
[13:36] <DktrKranz> directhex: is NEW shrinking now?
[13:37]  * DktrKranz has two packages in
[13:37] <directhex>  Package count in NEW: 361 |  Total Package count: 410
[13:37] <DktrKranz> gah!
[13:38] <directhex> indeed
[13:38] <DktrKranz> for package in NEW:
[13:38] <DktrKranz>     reject(package)
[13:38] <directhex> DktrKranz, i think it's spinlocking or something ;)
[13:39] <DktrKranz> heh
[13:39] <DktrKranz> I hope to see 3.0 packages support soon
[13:43] <c_korn> DktrKranz: is this debdiff fine? https://bugs.launchpad.net/ubuntu/jaunty/+source/scilab/+bug/272264/comments/44
[13:44] <ScottK> directhex: I had one come out of New recently, so there is some motion.
[13:44] <directhex> ScottK, binary new or source new? (even though the ftpmaster page doesn't distinguish)
[13:45] <ScottK> directhex: Source and they do distinguish.  Binary usually gets done more quickly.
[13:45] <DktrKranz> c_korn: not yet. You should use dch -i to add a new changelog entry, instead of mangling current one
[13:45] <c_korn> argh, I will get into it :P
[13:46] <directhex> ScottK, they distinguish in reality, but the ftp-master wobsite shows them both in the same queue, which is false
[13:49] <DktrKranz> directhex: ftp-master's NEW page is confusing, it lists binary NEW pkgs too, and it's really hard to say which are source NEW. I hope they have a better approach.
[13:49] <directhex> DktrKranz, someone did some hacking on that page recently. was it NCommander?
[13:50] <broonie> They're all equally NEW, the distinction is moer in teh internal sorting that DAK does.
[13:51] <ScottK> directhex: 'false' is really far too strong a word.
[13:51]  * broonie nods ScottK
[13:54] <directhex> perhaps it'd be clearer to me what was happening if i read debian-devel
[13:54] <directhex> but i try to avoid places that j00rg schilling might be
[13:54] <DktrKranz> :)
[13:54] <DktrKranz> directhex: once he mailed me
[13:54] <cody-somerville> ScottK, can you ack bug #193818 ?
[13:54] <broonie> directhex: There's one NEW queue. ftp-master process it in an order of their choosing (eg, doing quick things if they have little time).
[13:55] <directhex> DktrKranz, oh, me too. i had the audacity to file a bug on cdda2wav
[13:55] <broonie> directhex: the software provides a default sort for the queue when they go look at it which brings binary NEW stuff to the front.
[13:55] <broonie> (ftpmaster here being the humans that fulfil that role rather than the machine)
[13:56] <DktrKranz> directhex: mine was worse, he mailed me without previous contact by my side
[13:57] <DktrKranz> he saw I uploaded a revision of a similar package, and asked me some stuff about cdrtools
[13:57] <ScottK> cody-somerville: My first question would be why did slangasek decline it for Jaunty?
[13:57] <cody-somerville> ScottK, I imagine because someone nominated before FF or something.
[13:58] <cody-somerville> ScottK, However, in comment #16, he asks me if I could look at it this release
[13:58] <c_korn> DktrKranz: is this finally well done? http://pastebin.com/d7106162b
[13:58] <ScottK> cody-somerville: How tested is your new package?
[13:58] <ScottK> Yes.
[13:58] <cody-somerville> ScottK, I'm just building it now
[13:59] <cody-somerville> ScottK, However, 0.4 is rather obsolete.
[13:59] <DktrKranz> c_korn: much better now (at least for syntax).
[13:59] <NCommander> directhex, broonie, no, dak only had source NEWs, no binary NEWs like Ubuntu
[13:59] <NCommander> the binaries you are seeing are the binaries uploaded with the source package
[14:00] <c_korn> DktrKranz: should it be a for loop?
[14:00] <ScottK> cody-somerville: OK.  Tell me after you've tested it works (not just build) and sign up to be bug contact and I'll ack it.
[14:00] <directhex> broonie, i don't doubt that ftpmaster is a thankless, tedious, never-ending job, but it would be nice to get a better handle on why things can end up taking aeons. 2 months is a very long time, and the number of packages in NEW right now is mad. presumably there is post-release "stuff" to be done?
[14:01] <StevenK> NCommander: Actually, binary NEW is handled at the same time as source NEW
[14:01] <broonie> Some of it is folks taking a break after release.
[14:01] <broonie> NCommander: Not the case, *all* new binaries are NEW.
[14:02] <broonie> directhex: Some of it will be stuff being deliberately held up for transitions too.
[14:02] <directhex> broonie, ftpmaster goes on holiday just as everyone else is saying "lenny is out? quick, break the archive!" :D
[14:02] <DktrKranz> c_korn: not necessarily
[14:02] <NCommander> StevenK, dak uses the override for the source package, it doesn't have the concept of binary NEW unless I'm very much mistaken.
[14:02] <cody-somerville> ScottK, k
[14:02] <StevenK> NCommander: You're mistaken
[14:02] <broonie> NCommander: You're mistaken.
[14:02]  * StevenK high fives broonie 
[14:02] <ScottK> Is there an echo in here?
[14:03] <broonie> (IIRC the actual implementation is that everything *must* have an override so things without an override are NEW).
[14:03] <c_korn> DktrKranz: well, a simple "find . -name '*.po' -empty -delete" would be better?
[14:03] <DktrKranz> directhex: but people prepare NEW and keep them under the pillow to push it right after release, just to "break stuff" (tm)
[14:03] <NCommander> So I upload a package through dak, the source package and the initial binaries go through, the binaries for other architectures don't get stuck in a NEW queue like on Ubuntu
[14:03] <broonie> directhex: In general there's never been any guarantee on new processing and it does get backed up from time to time.
[14:04] <DktrKranz> c_korn: I guess they're equivalent
[14:04] <broonie> directhex: If it's particularly urgent then pinging *may* help, providing it doesn't annoy anyone :)
[14:04] <DktrKranz> just do not delete good translations, the other point is just cosmetic
[14:04] <directhex> broonie, i'm not looking for an SLA, just a general "waa, i'm right near the top but it's been *ages*"
[14:04] <directhex> broonie, absolutely people are entitled to time off
[14:05] <james_w> NCommander: but if you add a -dbg package in the next upload that will hit NEW
[14:05] <broonie> NCommander: Yes, the override is arch all
[14:05] <directhex> DktrKranz, well, yes, you don't want to upload things to unstable whilst testing is frozen
[14:05] <DktrKranz> in Italy we say: "patience is for the strong ones"
[14:05] <broonie> directhex: The queue has never been officially sorted, often the easy stuff is cherry-picked out first.
[14:05] <NCommander> james_w, oh ... sorry, when I think of binNEW, I think of Ubuntu's binNEW, as a per archietecture override.
[14:05] <NCommander> james_w, your right thats how dak works, but I wasn't thinking about it in the same terms.
[14:06] <directhex> DktrKranz, in the uk, we say "move yer arse!"
[14:06] <c_korn> DktrKranz: ok, thanks. https://bugs.launchpad.net/ubuntu/jaunty/+source/scilab/+bug/272264/comments/45 now I should wait for mok0?
[14:06] <directhex> ;)
[14:06] <DktrKranz> directhex: heh. we like sleeping :)
[14:17] <DktrKranz> c_korn: I haven't a build server handy, I'll probably review it this evening
[14:17] <DktrKranz> but thanks for the debdiff :)
[14:17] <c_korn> well the 0ubuntu1 made it to the install target. and this change should fix the translation error.
[14:30] <c_korn> DktrKranz: so are you assigned to scilab now? or should I tell mok0 when he comes online?
[14:34] <DktrKranz> c_korn: I can do it as well, but if mok0 (or someone else) grabs it first, I can't argue
[14:35] <c_korn> ok
[14:35] <DktrKranz> my main interest is to process FFe quicker once approved
[14:36] <c_korn> yeah, I know. FF is far over. now there needs some other work to be done
[14:37] <DktrKranz> or catching up regressions in time
[15:02] <RainCT> uhm.. indicator-applet isn't working here
[15:06] <RainCT> wow, I've found an emoticon representing jono -> http://flames.aptivastudio.com/images/smilies/icon_e_ugeek.gif  *g*
[15:07] <james_w> heh
[15:08] <bddebian> Heya gang
[15:09] <directhex> hello bddebian
[15:09] <bddebian> Hi directhex
[15:52] <pochu> any native speaker? what is correct, "a speficied port" or "an specified port"
[15:52] <pochu> I could also use "a given port" :)
[15:55] <directhex> a
[15:55] <directhex> technically, you use "an" to add a consonant between a and a word starting with a vowel
[15:55] <directhex> so "an apple" instead of "a apple"
[16:04] <Zarel> Vowel sound, to be exact.
[16:04] <Zarel> Hence little exceptions like "an hour"
[16:05] <directhex> oh, yes
[16:05] <directhex> whoopsie
[16:07] <ScottK> jpds: There was a bug against MoM with a patch for grab-merge.sh to use https.  Please make sure the version you are putting into ubuntu-dev-tools has that fix.
[16:14] <Toadstool> now I feel stupid, I was so convinced the next motu council meeting is tomorrow :p
[16:15] <Laney> when was it?
[16:15] <Aquina> today?
[16:15] <Toadstool> next week :)
[16:15] <Laney> heh
[16:15] <Aquina> So what about the marble packet? :D
[16:15] <Aquina> oh..
[16:24] <ScottK> jpds: Of course now I can't find the bug.  It was just changing http/https throughout.
[16:30] <ScottK> jpds: So I checked and it's the right one.  Nevermind.
[17:32] <vadi2> What is the proper way to supercede a package? (for example, the program was renamed)
[17:34] <slangasek> ScottK: because there are no controls on who nominates what for release, and all kinds of bugs show up on the nomination list that there's no reason we should track release-wise
[17:35] <ScottK> slangasek: OK.  Sounds reasonable.  Just wanted to make sure it wasn't something more specific.  Thanks.
[17:36] <maix> hi, is there a way to say "this packages requires package xy in a version between 1.0 and 2.0"?
[17:36] <maix> i cannot find docs about the requires header anywhere
[17:37] <ScottK> Use two separate depends.  One for the less than and one for the greater than.
[17:38] <goshawk> RainCT: hi
[17:39] <ScottK> maix: python (<< 2.7), python (>= 2.6), is a real live example from a package.
[17:39] <vadi2> how can I make it so package B supercedes package A, but when package A is removed, it doesn't want to remove package B?
[17:39] <maix> ok thanks
[17:39] <maix> what's the difference between << and < ?
[17:39] <maix> i know that from maths, but what does that mean with packages?
[17:40] <jpds> ScottK: OK (I thought they fixed the mod_ssl stuff).
[17:41] <jdong> maix: < > are not accepted
[17:41] <maix> oh *g*
[17:42] <jdong> see man deb-control for more info
[17:43] <maix> ah that's helpful, thanks
[17:43] <maix> another question: why is 1.0 and 1 not the same version?
[17:44] <ScottK> maix: Because they aren't the same.
[17:45] <maix> well ;)
[17:45] <jdong> maix: man deb-version? :)
[17:46] <jdong> (see under Sorting Algorithm)
[17:46] <jdong> the short answer is that it makes the sorting algorithm a simple concise no-surprises lexicographical comparison like traditional string-comparison operators.
[17:47] <maix> hm
[17:47] <maix> is there some convention to never use trailing .0s or something like that?
[17:48] <jdong> you mean in the debian/ubuntu part of the version string?
[17:50] <maix> no, anywhere
[17:50] <maix> or how shall i compare that else?
[17:51] <jdong> well we have no control (no pun intended) over how upstream projects version their projects.
[17:51] <maix> shall i write << 2.0 or << 2 or << 2.0.0 ?
[17:51] <jdong> that depends on how upstream versions their projects.
[17:51] <maix> of course, but one could change it
[17:51] <jdong> but for all intents and purposes they'd probably all do the same thing.
[17:52] <jdong> depending on how specifically upstream versions their product :)
[17:52] <Zarel_> https://launchpad.net/ubuntu/+source/warzone2100
[17:53] <maix> ah i'll just use 1.0, thats greater than 1 anyways so there'll be no problem
[17:53] <Zarel_> What does "current" mean in this context? -> intrepid  	current
[17:53] <maix> thank you two though
[17:54] <jdong> Zarel_: the latest released version of Ubuntu.
[17:54] <jdong> the field refers to the status of the Ubuntu release to the left.
[17:54] <Zarel_> jdong: So if it's "current", that means it should get bugfix updates, right?
[17:55] <jdong> Zarel_: in accordance to the StableReleaseUpdates policy.
[17:55] <jdong> !sru
[17:55] <jdong> that also applies to supported.
[18:01] <Zarel_> So only major bugs get fixed? :(
[18:20] <eMerzh> i'm looking for an advocate by a motu for my package http://revu.ubuntuwire.com/details.py?package=sqliteman .... thanks :)
[18:20] <ScottK> !backports | Zarel
[18:27] <Laney> huats: are you OK with python-webkitgtk? Noticed you said you were unwell earlier
[18:29] <Laney> jcfp: And you with sabnzbd?
[18:29] <Laney> chasing up a few uninstallable apps
[18:30] <jcfp> Laney: it's in the works, python-support giving me trouble although I seem to have found a way around that now
[18:30] <Laney> excellent
[18:30] <Laney> let me know and I'll sponsor it right away
[18:31] <Laney> oh, wait, it needed an FFe
[18:31] <Laney> let me know after you have that ;)
[18:44] <jcfp> Laney: if I patch the app to use /usr/bin/python2.5 in the shebang line, set debian/pyversions to 2.5 only and build in jaunty, ${Python:Depends} expands to include a hard depend on python (<< 2.6) which is uninstallable.
[18:44] <Laney> guh
[18:44] <jcfp> If I leave pyversions empty, it works fine; anything that includes 2.6 (like "2.5,2.6" or "2.5-") also works although the automatic deps on python don't make too much sense to me.
[18:45] <Laney> I'm really not very expert at python packaging
[18:45] <Laney> you might ask #debian-python or whatever their channel is
[18:45] <Laney> or wait for someone who knows more
[18:45] <huats> Laney: I am fine thanks
[18:46] <Laney> ah, good
[18:46] <huats> I am about to publish it
[18:46] <huats> thaks Laney
[18:46] <Laney> \o/
[18:47] <jcfp> I might just try asking on debian-python too, altough they haven't moved to python 2.6 yet
[18:48] <slytherin> need a bit help with gcc. I have a file which uses rand function (defined in stdlib.h). Even if the stdlib.h file is included I get error with gcc, undefined reference.
[18:55] <maxb> slytherin: could you pastebin buildlog?
[18:56] <slytherin> maxb: found the problem. wrong return type. :-(
[19:03] <Laney> Anyone able to help with some python/boost fun? Miro fails to build (and I'm told it is incompatible with 2.6 anyway) with errors relating to boost-python. http://orangesquash.org.uk/~laney/miro_ftbfs.txt
[19:29] <slytherin> StevenK: please let me know if I should file a bug for this. ubuntu-network-remix has dependency on cupsys-driver-gutenprint which is transition package. Also it has dependency on ubuntu-artwork which is redundant IMHO since there is also dependency on human-netbook-theme
[19:29] <fabrice_sp> Hi huats. anjuta is FTBFS. As I think I'm able to fix it, do you let me touch the package?
[19:30] <khashayar> Pencil (http://revu.ubuntuwire.com/details.py?upid=5149) is in good shape now and needs a couple of advocates. Is anyone up for it? (FYI, we're filing a FF exception for it). Thanks.
[19:31] <geser> fabrice_sp: create a patch and get it sponsored
[19:33] <fabrice_sp> geser, that's just the huats uploaded it few days ago, so I was wondering if he was working on it
[19:42] <jelmer> Is there some way to mark a bugreport relevant only to intrepid?
[19:43] <jelmer> I can see how to report a *new* bug for just intrepid, but moving an existing one seems to be harder
[19:43] <ScottK> jelmer: Yes.  Nominate for release and then mark it fixed/invalid/etc overall
[19:43] <ScottK> jelmer: I didn't hear back from you so I'm updating samba4.
[19:43] <jelmer> ScottK: Sorry
[19:44] <jelmer> ScottK: Ok
[19:45] <ScottK> jelmer: For future reference (when Debian gets 2.6) the changes are build-dep python2.5-dev -> python-dev and site-packages/*-packages in rules and the .install for the two python packages.
[19:46] <jelmer> ScottK, cool, thanks
[19:48] <huats> fabrice_sp: I have uploaded a new version today
[19:48] <huats> to fix that
[19:49] <fabrice_sp> ok. I'll look for others FTBFS :-)
[19:49] <fabrice_sp> thanks huats
[19:49] <huats> no problem fab
[19:49] <huats> no problem fabrice_sp
[19:49] <huats> and thanks :)
[19:50] <fabrice_sp> you can call me Fab ;-)
[19:50] <huats> fabrice_sp: it is easier with the completion :)
[19:51] <fabrice_sp> lol yes
[19:51] <Andre_Gondim> I'm trying to pack one program, but I don't if this debian/control file is correct http://paste.ubuntu.com/126894/
[19:59] <miik> why you dont put LimeWire in repo??
[20:00] <hyperair> miik: LimeWire isn't free.
[20:02] <miik> but its GPL
[20:02] <miik> wikipedia says so
[20:02] <miik> http://en.wikipedia.org/wiki/LimeWire -- License 	GNU General Public License
[20:05] <hyperair> hmm seriously?
[20:05] <hyperair> interesting
[20:05] <hyperair> well why don't you package it then? =)
[20:05] <huats> fabrice_sp: as you can see https://edge.launchpad.net/ubuntu/jaunty/+source/anjuta/2:2.25.902-0ubuntu2 anjuta builds now :)
[20:05] <hyperair> either way i think limewire's crippleware. limewire pro is where all the features are
[20:05] <jdong> heh it's not exactly without its marred history in the past.
[20:06] <jdong> I guess the correct answer to the question now is "because nobody has cared enough to put the time into packaging it"
[20:06] <hyperair> miik: i'd concentrate on frostwire.
[20:06] <miik> hyperair, icant find that in repo either
[20:06] <hyperair> but that has some issues with licensing or whatever
[20:06] <hyperair> miik: yeah because there were licensing issues or something
[20:06] <hyperair> even if it says it's GPL
[20:07] <hyperair> https://bugs.launchpad.net/ubuntu/+bug/94011
[20:07]  * slytherin loves transmission
[20:07] <miik> oh
[20:07] <jdong> indeed.
[20:07] <jdong> not MUCH different from the azureus debacles in the past.
[20:08] <jdong> i.e. the main thing is FOSS but they bundle a couple native precompiled libs
[20:08] <miik> but smeone put frostwire request 2 years ago
[20:08] <miik> they dont put it in repo
[20:08] <jdong> and figuring out what the heck they are is more of a challenge than expected.
[20:08] <jdong> does the upsteram source STILL bundle precompiled libraries?
[20:08] <ScottK> miik: There are a lot more requests than people willing to do the work.
[20:09] <miik> :(
[20:09] <miik> well, what does all the guys mark pays does?
[20:09] <rgreening> ScottK: I started on it.. but ran into packaging issues :)
[20:09] <ScottK> .jar is a binary, right?
[20:09]  * ScottK knows about zip about Java
[20:09] <jdong> ScottK: in most cases yes
[20:09] <jdong> ScottK: it's a ... no pun intended.. zip file.
[20:09] <miik> i wish redhat, gentoo, ubuntu, suse all shared repository
[20:09] <jdong> in it can be source or .class binaries
[20:09] <ScottK> limewire is chock full of them.
[20:09] <slytherin> ScottK: you can say that
[20:10] <jdong> a "runnable tarball" if that sounds any better :D
[20:11] <slytherin> does anyone know how to debug issues with cdrom device access?
[20:11] <ScottK> miik: It'd take a person who was reasonably expert in Java, Debian packaging, and licensing to go through their tarball as see if it was actually legal to go in the repositories.
[20:12] <miik> its GPL, i would assume it is...
[20:12] <ScottK> miik: One common problem we hit with Java packages is they are licensed GPL so was can't distribute without the source, but then they don't provide the source.
[20:12] <miik> oh
[20:12] <jdong> miik: a lot of things say they are GPL are not truly GPL compliant :)
[20:12] <ScottK> So without that, we can't have it in the repo at all.
[20:12] <miik> oh
[20:12] <miik> but if i want use limewire on windows, i can just do that...
[20:13] <miik> but on ubuntu, i cant =/
[20:13] <ScottK> Dunno if that's the case here at all.
[20:13] <jdong> well if it is truly Java it shouldn't be hard to run from jar.
[20:13] <ScottK> Limeware could make .debs and distribute them.  We can't.
[20:13] <rgreening> Limewire has debs iirc
[20:13] <rgreening> and so does frostwire
[20:14] <slytherin> does limewire or frostwire use bittorrent protocol?
[20:15] <jdong> slytherin: partly
[20:15] <jdong> they support it but AFAIK theyare primarily gnutella-ish clients
[20:17] <RainCT> thekorn: nice screencast :)
[20:18] <slytherin> packaging big java application from scratch can be frustrating experience at times. I experienced it first hand with jmeter.
[20:20] <thekorn> RainCT, thanks, I plan to push leonov a bit more over the next few weeks
[20:20] <miik> well aslong as you cant run open source software on linux, it seems windows is a better platform for running open source software
[20:20] <miik> open source software is better supported on windows than on linux
[20:20] <miik> i can run limewire on windows, but not on linux
[20:21] <miik> so people should migrate from linux to windows in order to better use open source software to save costs and get a lower tco
[20:25] <miik> i can use cross-platform applications such as limewire on windows
[20:25] <slytherin> miik: one application != open source software.
[20:25] <miik> but i cannot use cross-platform applications on linux
[20:26] <miik> there are thousand applications
[20:26] <miik> just needs-packaging on bugs.ubuntu.com
[20:26] <slytherin> miik: and I fail to understand why you can't run limewire as distributed by their website on linux
[20:28] <fabrice_sp> huats, great! :-) You just added a build dependency, right? Oh: I can see it in the changelog :-) By the way, it still appears as FTBFS in ubuntuwire
[20:29] <slytherin> RainCT: which screencast are you talking about?
[20:30] <slytherin> fabrice_sp: ftbfs page usually takes a day for update.
[20:30] <fabrice_sp> ok
[20:32] <fabrice_sp> by the way, I have a sync request that has been acked to authorize the FFE. Do I nned to subscribe MOTU or directly the Arhcive admin?
[20:33] <fabrice_sp> it's bug #336904
[20:33] <Laney> do you need sponsorship?
[20:33] <slytherin> fabrice_sp: i believe motu since someone will need to add an ack that it builds fine.
[20:34] <thekorn> slytherin, I *think* he talked about http://launchpadlibrarian.net/23523147/leonov_multible_content_MainContent.ogv
[20:34] <fabrice_sp> Laney, I just applied yesterday to U-C-D, so no upload rights for the moment :-)
[20:34] <Laney> then you need sponsorship
[20:34] <Laney> u-u-s it is!
[20:35] <fabrice_sp> ok. As motu-release members are motus, I had a doubt. Thanks!
[20:35] <fabrice_sp> thanks Laney and slytherin
[20:38]  * slytherin calls it a day
[20:39] <Laney> oh dear
[20:39] <RainCT> thekorn: Great. I'd get back to do some work, but I'm already overloaded with other stuff and school :(
[20:39] <Laney> muting my audio makes a horrible sound come out of the speakers
[20:51] <huats> fabrice_sp: I guess there is a cache.. that is why it is still FTBFS
[20:55] <Laney> anyone got a sync ack script?
[20:56] <ajmitch> why would you use a script for such a thing? :)
[20:57] <Laney> because otherwise acking is several clicks
[20:57] <ajmitch> though you'd at least be looking at the LP bug anyway
[20:58] <ScottK> Laney: I'd suggest filing bugs against LP asking for the workflow to be streamlined.
[20:58] <Laney> ScottK: Isn't syncing support coming to LP anyway?
[20:59] <ScottK> Laney: I've heard so.
[20:59] <Laney> me too
[20:59] <ScottK> No idea if it's actually going to happen.
[20:59]  * Laney asks
[21:09] <joaopinto> what is the max allowed length for a package name ?
[21:17] <RainCT> joaopinto: how long is your name?
[21:18] <joaopinto> RainCT, that does not answer my question, I am defining a table and I need a max value for the package name field
[21:18] <joaopinto> that is not
[21:20] <RainCT> joaopinto: Debian Policy doesn't say anything about the length (file:///usr/share/doc/debian-policy/policy.html/ch-controlfields.html#s-f-Package)
[21:20] <joaopinto> RainCT, I have read the policy :P
[21:21] <maxb> I don't think there is a maximum length. In practice it's a matter of "Don't be silly, or the archive admins will reject it from NEW"
[21:23] <RainCT> joaopinto: Looking at package names on Synaptic, I guess with 50 characters you'll be save.. (But I'm just guessing!)
[21:23] <joaopinto> ok, i'll use 80 just in case
[21:25] <maxb> libmaypole-plugin-authentication-usersessioncookie-perl is 55 chars :-)
[21:26] <maxb> and 1.9.1~b3~hg20090205r23182+nobinonly-0ubuntu1 is the longest version string, at 44 chars!
[21:27] <joaopinto> ouch, i need to increase the version len
[21:28] <maxb> whilst the longest Source field is "openoffice.org-dictionaries (1:3.0.1~rc1-3ubuntu1)" at 50 chars
[21:37]  * porthose kicks his router for being a pain in the arse
[21:37] <porthose> sorry for the noise
[21:40] <RainCT> porthose: bah, I've done worse monologues ;)
[21:45] <c_korn> as I see scilab was uploaded again. where can I see it waiting for building?
[21:46] <porthose> RainCT: it's getting a little old, probable need to replace it;-)
[21:52] <RainCT> c_korn: https://edge.launchpad.net/ubuntu/+source/scilab
[21:52] <RainCT> c_korn: click on the version number and perhaps some other links and you'll end up at a page with info about the build
[21:53] <c_korn> RainCT: ah thanks. I did not find the link to launchpad.../+source
[21:54] <Laney> nice work huats! (py-webkit-gtk)
[21:54]  * Laney waits expectantly for a build
[22:04] <mok0> c_korn: https://edge.launchpad.net/ubuntu/jaunty/+builds?build_text=scilab&build_state=all
[22:04] <mok0> c_korn: still pending
[22:05] <c_korn> mok0: I see. it should build fine now (hopefully)