[00:05] <dolanor> I can edit the patch itself, but I cannot create another patch :/
[00:06] <dolanor> for editing the same, it applies and patch itself, and for editing a new one, it applies the first one, like before ... But fail ...
[00:11] <dolanor> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399308 : workaround is to add some cdbs var in debian/rules to scan deeper than only 1 0 or 2
[00:23] <binarymutant> this might be a silly question, but can I request a sync from Debian if the package is already in Ubuntu? My package in Debian is much more cleaner and precise than the one already in Ubuntu
[00:24] <directhex> binarymutant, how do the version numbers look?
[00:24] <binarymutant> 0ubuntu1 and -1 in debian
[00:24] <directhex> then requestsync it
[00:25] <dtchen> IFF the orig.tar.gz is identical.
[00:25] <binarymutant> cool thanks
[00:25] <binarymutant> they are
[00:25] <directhex> if it's not, then spank spank
[00:41] <sladen> directhex: how do I stop dh_something or other trying to strip this mono binary?
[00:41] <directhex> sladen, generally, or for injecting into a dedicated -dbg package?
[00:49] <Davedan> I'm using Pre-Invoke and Post-Invoke inside /etc/apt/apt.conf.d/ to run scripts before and after dpkg is running
[00:49] <Davedan> can I pass a value between them? assign a variable in the pre-invoke and pass it to the post-invoke?
[01:00] <sladen> directhex: it's a train simulator.  the source builds one binary in bin/Debug/OpenBVE.exe
[01:00] <sladen> directhex: which I then install to debian/openbve
[01:01] <anakron> hi all
[01:01] <Davedan> where should scripts of a package be placed in the file system?
[01:01] <directhex> sladen, you could skip calling dh_clistrip
[01:01] <anakron> how i can see wich patches are in a source package
[01:01] <Davedan> a python script for example
[01:01] <directhex> anakron, look in debian/patches ?
[01:01] <anakron> ops
[01:01] <anakron> xd
[01:01] <anakron> and how i can apply some changes with a debdiff
[01:02] <anakron> if any patch is applied
[01:02] <anakron> debian/patches >> is not there
[01:02] <anakron> but a patch is applied
[01:02] <directhex> then they've applied patches directly in diff.gz
[01:03] <sladen> directhex: this is what's confusing me, I don't have that;  only  dh_clifixperms  and  dh_clideps -d
[01:03] <directhex> an act which ought to carry a spank penalty
[01:03] <anakron> :O ok
[01:03] <anakron> so, i must apply this patch and then apply mi diff file
[01:03] <directhex> sladen, does the mdb get created in your debian/tmp staging folder? is it missing from a .install file?
[01:03] <anakron> or, if it's not necessary, i can make only a debdiff file and then upload to the bug report
[01:03] <anakron> i test it and it runs ok
[01:04] <sladen> directhex: oh, there is an .mdb file too;  is that important;  what should I do with it?
[01:04] <anakron> but
[01:04] <anakron> i need to know something
[01:04] <directhex> sladen, that's the debugging symbols.
[01:05] <sladen> directhex: I was assuming I just dump this 'OpenBVE.exe' file to  /usr/games/openbve  (no .exe)
[01:05] <sladen> directhex: oh right, where do I put them?
[01:05] <directhex> sladen, same location as your .exe
[01:05] <directhex> sladen, you should always write a trivial script to launch your app, not rely on executing .exe files directly
[01:05] <RAOF> sladen: Normal proceedure would be to make an openbve shell script that calls OpenBVE.exe, rather than assuming binfmt is working.
[01:06] <directhex> RAOF, since binfmt is linux-only
[01:06] <sladen> oh.  righto.  I thought binfmt was good for everything
[01:07] <sladen> gah messy, so I actually stick it in /usr/lib/openbve/OpenBVE.exe  along with the .mdb and then stick a shell script in /usr/games/ ?
[01:07] <directhex> sladen, nope. debian has more kernels than just linux, so needs to support non-linux things ;)
[01:07] <directhex> sladen, yes, that's correct procedure
[01:07] <lifeless> directhex: it does?
[01:07] <lifeless> directhex: far as I know alternate kernels for debian are not part of the release set
[01:07] <lifeless> directhex: so they don't exist
[01:08] <sladen> does the same apply for Java?
[01:08] <directhex> lifeless, some of us are noble & sweet
[01:08] <directhex> sladen, yeah. java can technically run through binfmt, but you should write a launcher script
[01:08] <lifeless> directhex: doing more work to support a mythical beast has many labels :P
[01:09] <lifeless> sladen: FWIW, I'd argue that wrapper scripts are dead space, duplicate code with whats in binfmt, and shouldn't be used :)
[01:09] <directhex> fwiw we will reject any use of binfmt from pkg-cli-apps
[01:09] <sladen> lifeless: I agree with you
[01:09] <lifeless> directhex: well, its your call - I don't package mono stuff
[01:10] <sladen> directhex: right, so (looking at "trivial" /usr/bin/fspot) can I not just do  env mono /real/exec "$*"
[01:11] <directhex> sladen, let me find a decent minimal one. f-spot et al are complex
[01:12] <lifeless> seriously though, what kernels (win32 is not a kernel, and could run mono stuff directly anyway) don't support a binfmt equivalent?
[01:12] <hyperair> lifeless: win32 only runs mono stuff directly if you've got the framework installed
[01:13] <sladen> lifeless: binfmt also has the benefit of workig +x bits
[01:13] <lifeless> hyperair: and it can't if its not installed;
[01:13] <directhex> exec /usr/bin/mono /usr/lib/nemerle/nemish.exe "$@"
[01:13] <lifeless> hyperair: so its really a non-issue
[01:13] <directhex> okay, examples
[01:13] <hyperair> lifeless: the framework on win32 is equivalent to mono on linux
[01:14] <directhex> 1) conflicts with wine binfmt
[01:14] <directhex> 2) conflicts with multiple CLI environments
[01:14] <directhex> 3) only useful for trivial cases
[01:15] <directhex> 4) it's in the policy docs - http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-file-locations
[01:16] <lifeless> directhex: 1) bug in wine, 2) uhhhh, isn't that like 'conflicts with multiple libc environments' ?(e.g. bug in the linker), 3) working simply doesn't seem trivial to me
[01:16] <hyperair> lifeless: i don't see how 1 is a bug of wine. generally you'd want to run .exe stuff in wine, because not all .exe files are C#
[01:16] <directhex> lifeless, bring it up with pkg-mono list. it's 1am and i really don't care at this point
[01:17] <lifeless> directhex: sure, I mean, I'm not trying to troll, but the reasons really weren't gelling for me
[01:17] <hyperair> lifeless: also i don't think i fancy starting up my C# apps with a .exe command
[01:17] <lifeless> I can see there are some issues
[01:17] <lifeless> interestingly policy says 'so it works without the .exe extension'
[01:17] <sladen> this is like saying that you can't tell an ODF file from a Java .jar from a .zip
[01:17] <lifeless> and provides no other reasons  (and thats a reason I can understand :P)
[01:19] <sladen> the answer is that you look a little further;  which is why binfmt calls out to a script that then runs either mono or wine, or dosbox
[01:19] <hyperair> sladen: they have different extensions
[01:19] <sladen> hyperair: we *do not care* about extensions on Unix :)
[01:19] <directhex> why go to added effort to cripple non-linux-kernel systems?
[01:20] <directhex> most dists don't even HAVE auto-configured binfmt support, let alone use it
[01:20] <sladen> luckily Debian/Ubuntu has
[01:21] <hyperair> sladen: well then, tell me the difference between a C# exe that i want to run on wine, and a C# exe i want to run on mono
[01:24] <directhex> hyperair, the difference can be detected, when binfmt is working. see /usr/lib/cli/binfmt-detector-cli
[01:26] <directhex> anyway, bedtime.
[01:26] <sladen>  or rather the difference is /already/ detected and has "just worked" for several years automagically
[01:27] <RAOF> directhex: Isn't it policy to exec /usr/bin/cli rather than /usr/bin/mono, should GNU Portable .NET ever do anything useful?
[01:28] <sladen> hyperair: nine out of ten cat owners who can't tell the difference prefer the faster codepath
[01:29] <hyperair> sladen: well i'm not a cat owner, and i prefer not having a .exe behind commands i run
[01:31] <sladen> hyperair: I was just going to install it without the .exe
[01:31] <sladen> hyperair: like I tend to install useful shell scripts without the .sh
[01:32] <hyperair> sladen: well if you're so sure about this, take it up to the pkg-mono list
[01:32] <sladen> hyperair: or useful Python programs without the .py
[01:32] <hyperair> sladen: if you can make them change the policy then by all means do so
[01:32] <hyperair> sladen: otherwise, suck it up and stick with the policy
[01:35] <sladen> hyperair: I guess my fear (the same as lifeless') is that somebody thought it would be a good idea, so it has been perpetuated
[01:36] <hyperair> somebody thought what would be a good idea?
[01:36] <lifeless> the last 30 minutes of discussion
[01:38] <sladen> maybe not all kernels support symlinks ;-)
[01:38] <lifeless> sladen: does qnx ? :P
[01:38] <hyperair> lifeless: i've only been here for the past 20
[01:39] <hyperair> sladen: i thought it was more to filesystem support
[01:39] <lifeless> 12:07->12:35, 28 minutes
[01:39] <hyperair> sladen: besides, it's in the posix standard, is it not?
[01:39]  * hyperair has been around from 9:11 onwards
[01:40] <hyperair> lifeless: the first message i saw was "find a decent one ... f-spot is complex"
[01:40] <lifeless> 12:07 -!- hyperair [n=hyperair@155.69.199.211] has joined #ubuntu-motu
[01:41] <hyperair> lifeless: install ntp =p your time's off by 4 minutes or so
[01:41] <lifeless> hyperair: it doesn't matter if it is, given that the range I quoted is consistently off :)
[01:41] <sladen> hyperair: nah, lifeless just caches time queries;  it speeds them up
[01:41] <lifeless> also, ntp is installed, I'll have to check whats going on if its off
[01:42] <hyperair> heh
[01:42] <hyperair> no on second thoughts i think my ntp's faul
[01:42] <hyperair> ty
[01:42] <lifeless> have I mentioned i hate the 'open group'
[01:43] <hyperair> what's open group?
[01:43] <lifeless> your comment about symlinks sent me checking susv3
[01:44] <lifeless> I haven't found a fs requirement yet; however interestingly 'symlink()' doesn't have a defined error code for 'my fs cannot do symlinks'
[01:46] <lifeless> and statvfs is just useless
[01:49] <lifeless> sladen: http://man.chinaunix.net/unix/susv3/xrat/xbd_chap03.html
[01:49] <lifeless> sladen: read the section on symbolic links, you'll cry
[01:57] <ScottK> I'd say if an admin chooses to use an FS that doesn't support symlinks, they've earned whatever pain that brings.
[02:08] <lifeless> ScottK: you just condemned all the windows sysadmins out there :P
[02:09] <ScottK> lifeless: Yes, and?
[02:09] <lifeless> ScottK: and nothing :)
[02:09] <ScottK> OK.  Just checking.
[02:22] <sladen> lifeless: so Apple's AFC protcol that they talk down the USBto iPhones/iTouches has the capability to make and delete symlinks, but not to readlink them
[02:24] <lifeless> sladen: swwwwwet
[02:26] <sladen> lifeless: so if you dir() the directory, you know it's a symlink, but can't display any information about it as if you stat() it, you get the destination file (although you can't tell where that is either)
[02:37] <lifeless> sladen: special
[02:37] <lifeless> so very very special
[03:06]  * ScottK notes it's 4 days until feature freeze, so he better get to work on writing the new upstream release.
[05:18] <TheMuso> Where has the subscribers list from the bug view page gone?
[05:19] <lifeless> these are not the subscribers you are looking for
[05:19]  * lifeless waves
[05:19] <TheMuso> heh
[05:25] <StevenK> TheMuso: I can see the subscribers list for bug 1, for example
[05:25] <TheMuso> Hrm, ok they are in firefox, but not elinks
[05:25] <lifeless> StevenK: thats not very nice
[05:25]  * TheMuso probably needs a reason to change to using firefox...
[05:25] <lifeless> poor ubot tu
[05:26] <StevenK> TheMuso: I'm guessing Firefox is a fair bit harder to drive?
[05:27] <TheMuso> StevenK: Its adjusting to a new workflow/way of working with webpages efficiently.
[05:28] <TheMuso> If I could get firefox to display pages similarly to how elinks does. i.e remove all formatting so I view them in a linear ashion (which firefox more than likely can do, things would be better.
[05:28] <TheMuso> Its just sitting down and changing/setting things, and then learning the new ways.
[05:40] <ScottK> TheMuso: powerpc seems to be just I thing of beauty.  Everything I retry the worked on the supported archs seems to build just fine.
[05:42] <ScottK> ia64 seems to be going well too.
[05:44] <TheMuso> ScottK: Yay! I've read up a bit on that sparc bug, I need to find a sane fix for the kernel, test build it on a sparc box, and then test glibc as well, since it failed in a similar fashion. sistpotty suggested I grab an account on spooky for that.
[05:44] <TheMuso> So I will do that once I am done with work for the day.
[05:45] <ScottK> TheMuso: Glad to hear it.  The only other thing I've run into on sparc is a boost thing that I think I have a fix for.
[05:45] <TheMuso> ok cool
[05:46] <ScottK> TheMuso: Would you be able to perhaps test it on spooky?
[05:46] <TheMuso> ScottK: Once I get an account, yes sure.
[05:46] <ScottK> It's rebuild boost and then built akonadi against the new boost.
[05:46] <ScottK> TheMuso: The proposed change is in my PPA.
[05:47] <ScottK> NCommander was going to test it, but I gather he's somewhat ill at that moment.
[05:47] <dholbach> good morning
[05:47] <ScottK> Good morning.
[05:47] <StevenK> TheMuso: You uploaded a linux-ports-meta, right?
[05:47] <TheMuso> ScottK: ok thanks
[05:47] <TheMuso> StevenK: Yep, I don't want to change seeds et al yet because therre is likely an ABI bump coming with the next upload.
[05:48] <StevenK> TheMuso: So I can't NBS out 27-1? :-/
[05:48] <TheMuso> StevenK: I have to enable ubuntu modles for ports arches yet, to give squashfs/etc for livecd running etc, which will likely bump it.
[05:48] <TheMuso> StevenK: Alright, if you really want to NBS that, I'll change seeds/d-i.
[05:50]  * TheMuso will do that later this afternoon.
[05:50] <TheMuso> once I have finished work.
[05:50] <StevenK> TheMuso: I would, because NBS is currently at 287 packages due to linux-ports and the -7 kernel
[05:50] <TheMuso> StevenK: Right ok.
[05:50] <StevenK> Actually, upload -2 ports, and we'll crack 400 :-)
[05:51] <TheMuso> -2 ports may not be for a day or so, so I can do those changes        y.
[06:11] <dholbach> Laney: did a bit of sponsoring over the weekend? :-)
[06:50] <didrocks> morning o/
[06:50] <dholbach> hey didrocks, hey iulian, hey quadrispro
[06:50] <quadrispro> hi dholbach
[06:50] <dholbach> quadrispro: xom FTBFS again
[06:51] <didrocks> hey dholbach & quadrispro :)
[06:51] <quadrispro> oh, looking it now
[06:51] <iulian> Good morning dholbach and all.
[06:57] <quadrispro> dholbach:  [javac] java.lang.StackOverflowError   =-O
[06:57] <dholbach> quadrispro: maybe doko or slytherin or koon have an idea there?
[06:58] <slytherin> dholbach: I was wondering if you could help me understand this problem. dist-upgrading my ibook (powerpc) does not pull latest kernel images. Is theer anything wrong with ubuntu-* meta packages?
[06:58] <slytherin> quadrispro: which package is that?
[06:58] <quadrispro> hi slytherin! we're talking about xom
[06:58] <dholbach> slytherin: <TheMuso> StevenK: Yep, I don't want to change seeds et al yet because therre is likely an ABI bump coming with the next upload.
[06:59] <dholbach> slytherin: usually I'm not the best person to talk to about kernel images :-)
[06:59] <slytherin> dholbach: Thanks for info.
[06:59] <quadrispro> slytherin: it FTBFS again, but in my pbuilder it was built fine
[06:59] <slytherin> quadrispro: you are trying to convert it to default-j* packages?
[07:00] <TheMuso> slytherin: you should have recieved a linux-powerpc package. Did you not?
[07:01] <slytherin> TheMuso: no. That is the reason I am wondering what is wrong.
[07:01] <slytherin> I installed linux-image-powerpc separately which then pulled the latest image.
[07:01] <quadrispro> slytherin: mmm... what I have to do to convert it?
[07:01] <TheMuso> slytherin: hrm, it was built.
[07:02] <TheMuso> slytherin: Ok a manual pull got it.
[07:02] <slytherin> quadrispro: last time I and calc tried it failed with same error.
[07:02] <TheMuso> slytherin: The reason, as dholbach pointed out, is the seeds haven't been adjusted yet which is why you didn't get them straight away./
[07:02] <TheMuso> However I will be changing that shortly.
[07:03] <slytherin> Cool. So nothing wrong on my machine. :-)
[07:03] <TheMuso> No.
[07:04] <slytherin> quadrispro: I am not sure what the error is. I haven't actually looked into the code.
[07:05] <quadrispro> incredible... it happens a stack overflow during building process
[07:08] <quadrispro> heh, I have to go, slytherin: see you later
[07:09] <quadrispro> dholbach: I'm very sorry, I'll try to fix that
[07:09] <dholbach> quadrispro: no worries
[07:10] <slytherin> quadrispro: best luck with fixing that. :-)
[07:52] <Nicke> dfdfdfdfdsfsdfsdf
[08:23] <Aquina> hy
[09:18] <directhex> DktrKranz, well i have MD2 in a package, but i'd like to resolve the "throws nasty error on startup and opening projects" issue before letting you take a look ;)
[09:23] <DktrKranz> directhex: sure. I'll have a mono enthusiast to look at it too
[09:24] <DktrKranz> just to have another opinion about it
[09:28] <directhex> waiting for my jaunty VM to build first
[09:32] <DktrKranz> directhex: I'll discuss about it at the motu-release meeting later today (19 UTC)
[09:32] <directhex> DktrKranz, thank you
[09:33] <DktrKranz> if you want to be there, #ubuntu-meeting is the place :)
[09:34] <directhex> i should be about at 7
[09:44] <khashayar> I'm trying to write a get-orig-source section that repacks the upstream source in a certain way (excluding two dirs). Is there any way in the script to let a variable inherit the upstream filename that uscan downloads?
[09:45] <slytherin> khashayar: check jcharts source in jaunty.
[09:45] <khashayar> slytherin: thanks!
[10:09] <pochu> any french guy around?
[11:02] <DktrKranz> directhex: have you ever seen something similar to " error CS0234: The type or namespace name `PanelAppletBackgroundType' does not exist in the namespace `Gnome'. Are you missing an assembly reference?"
[11:03] <directhex> DktrKranz, i've never used gnome#, truth be told.
[11:03] <directhex> DktrKranz, is this on jaunty?
[11:03] <DktrKranz> it happens compiling drapes on jaunty
[11:04] <directhex> DktrKranz, does it have a build-dep on libgnomepanel2.24-cil?
[11:04] <directhex> DktrKranz, that's one of the API breaks in gnome# 2.24, splitting gnome panel functions into its own lib
[11:05] <DktrKranz> I look
[11:06] <directhex> it'll also need a reference to that lib (easiest to add a -pkg:gnome-panel-sharp-2.24 to the csc command line)
[11:09] <Koon> pochu: yes
[11:10] <DktrKranz> directhex: that seems to solve it, thanks ;)
[11:10] <directhex> DktrKranz, one of the few apps where gnome# 2.24 needs more than sed on debian/control it seems
[11:11] <directhex> DktrKranz, please be sure to pass patches to debian, post-lenny these things matter to us
[11:13] <hanska> DktrKranz: be a good boy :P
[11:13] <directhex> eek, a hanska
[11:13] <hanska> directhex: am I so ugly? :(
[11:13]  * directhex uploads MD2 with debugging symbols enabled to LP
[11:14] <DktrKranz> directhex: sure. I plan to have that transition completed in a couple of days, after that I'll have a look at the deltas introduced and pass them to hanska to push on SVN :)
[11:14] <hanska> directhex: on #debian-it they use "hanska" as a bad word... like "you're a hanska!"
[11:14] <hanska> DktrKranz: sure :)
[11:14] <hanska> DktrKranz: meebey told me to work on gnome# transition :(
[11:14] <DktrKranz> hanska: well... I "worked" on it too
[11:14] <DktrKranz> basically by running sed :)
[11:15] <hanska> lol
[11:15] <hanska> DktrKranz: no, I mean, *serious* working... ABI/API compatibility, for example :/
[11:15] <DktrKranz> heh
[11:17] <directhex> i386 build of monodevelop 1.9.2+dfsg-1~pre1~jaunty3 in ubuntu jaunty RELEASE
[11:17] <directhex> Build started 1 minute ago on samarium (virtual)
[11:18] <hanska> directhex: \o/
[11:18] <hanska> directhex: btw, md2 is broken here
[11:18] <hanska> (or did meebey update it?)
[11:18] <directhex> hanska, error message about accessing a dir, on startup?
[11:18] <lidaobing> what's the freeze day of ubuntu 9.04? (I mean does not accept new package from motu.)
[11:18] <hanska> directhex: you mean MOZILLA_foo? no
[11:18] <hanska> directhex: I mean opening md1 projects ;)
[11:19] <directhex> hanska, meh, that's a warning
[11:19] <directhex> lidaobing, tomorrow
[11:19] <directhex> lidaobing, unless you give someone in motu-release a relaxing massage
[11:19] <slytherin> lidaobing: 19th Feb IIRC.
[11:19] <DktrKranz> hanska: I guess you don't need package adjustments, isn't it?
[11:20] <lidaobing> directhex, slytherin thanks
[11:20] <hanska> DktrKranz: no, it's a code bug (Exceptions being thrown)
[11:21] <directhex> hanska, ~jaunty3 is ~pre1 with all the mdb files in place, for great debugging justice
[11:21] <hanska> directhex: \o/
[11:21] <hanska> directhex: apropos, did you know about debug.debian.net?
[11:22] <directhex> hanska, no, but it doesn't do dh_clistrip does it ;)
[11:22] <hanska> directhex: nope, but we could hack it :9
[11:22] <DktrKranz> hanska: so... most of the packages were just mangled that way
[11:22] <hanska> s/9/)/
[11:23] <slytherin> When is the next motu-release meeting?
[11:23] <directhex> 7pm
[11:23] <DktrKranz> slytherin: today, 19 UTC
[11:24] <slytherin> oh, that means 2am for me. :-(
[11:24] <DktrKranz> a bit late...
[11:24] <directhex> 2am is fine with a bit of beer to fuel you
[11:25] <DktrKranz> have you some items you want to discuss?
[11:25] <slytherin> directhex: I don't drink beer.
[11:25] <directhex> you're doomed then :|
[11:26] <slytherin> DktrKranz: yes there is one. I have been working on jmeter package for some time. And I am 2 build deps away from completion.
[11:26] <slytherin> I was hoping to complete them over weekend but couldn't.
[11:27] <DktrKranz> slytherin: are b-d NEW?
[11:27] <slytherin> DktrKranz: no they are not.
[11:28] <DktrKranz> good, we decided to limit NEW a lot past FF
[11:30] <slytherin> directhex: FF is 19th as per https://wiki.ubuntu.com/JauntyReleaseSchedule
[11:30] <slytherin> DktrKranz: I hope I can complete them before 19th.
[11:30]  * DktrKranz moves to lunch
[11:30] <DktrKranz> slytherin: if you can't, FFe are still permitted
[11:30] <directhex> slytherin, close enough. i've been worrying about tursday to stay ahead of the curve, then!
[11:31] <slytherin> DktrKranz: I will see if I can keep only jmeter for FFe. I should be able to package rest of the b-d before FF.
[11:31] <directhex> slytherin, you're a java guy. is JNI as mind-bogglingly moronic as it looks?
[11:32] <slytherin> directhex: I never worked in anything JNI. :-(
[11:32] <directhex> slytherin, http://www.koushikdutta.com/2009/01/jni-in-android-and-foreword-of-why-jni.html suggests you never want to
[11:32] <slytherin> directhex: I have mostly worked in web apps.
[11:33] <directhex> slytherin, part of me wants to package an asp.net webapp, just to learn how & find bugs in our asp.net stack packaging
[11:34] <incorrect> I am trying to figure where dpkg-buildpackage is breaking,  is there anyway to get it to step through the rules?
[11:35] <slytherin> directhex: part of me has been wanting to write struts based web app just to check how good is the stack packaged in Debian/Ubuntu. :-)
[11:35] <slytherin> incorrect: paste your error somewhere in pastebin.
[11:36] <incorrect> http://pastebin.ubuntu.com/118805/
[11:39] <incorrect> I am trying to package openldap 2.4.14
[11:39] <incorrect> as that resolves more multimaster issues
[11:39] <geser> my quick guess would be, check the upstream Makefile
[11:59] <incorrect> yep it had totally the wrong dir structure
[12:00] <c_korn> slytherin: hello. I just wanted to notice you that xmlgraphics-common 1.3.1 is now in jaunty and fop should compile now
[12:04] <incorrect> all the upstream make files are generated by something, but i don't know what
[12:07] <james_w> hey stefanlsd
[12:07] <stefanlsd> hey james_w
[12:28] <slytherin> c_korn: I will check fop tonight
[12:28] <c_korn> ok, thank you
[12:45] <AnAnt> Hello,  can someone review http://revu.ubuntuwire.com/details.py?upid=5147 ?
[13:39] <slytherin> calc: Did we ever have any discussion about moving libbcprov-java to main (which is build-dep of libitext-java)?
[13:43] <slytherin> how can I give back all the failed builds for a package?
[13:43] <DktrKranz> slytherin: is it in universe?
[13:43] <slytherin> DktrKranz: yes
[13:44] <DktrKranz> slytherin: if you have ubuntu-dev-tools, run buildd <packagename> jaunty retry
[13:44] <slytherin> let me try
[13:45] <slytherin> DktrKranz: cool. It worked.
[13:48] <DktrKranz> :)
[14:28] <Q-FUNK> No credentials found for 'ubuntu-dev-tools', please see the manage-credentials manpage for help on how to create one for this consumer.
[14:28] <Q-FUNK> -- was there some change in how requestsync works?
[14:28] <dholbach> yes, it uses launchpadlib now
[14:28] <Q-FUNK> ok
[14:28] <Q-FUNK> i have the cookie file but it gives me this
[14:29] <dholbach> did you check out the manpage? :-)
[14:29] <jpds> Q-FUNK: See the buttom of: 'man manage-credentials'.
[14:29] <dholbach> the cookie was used by python-launchpad-bugs
[14:30] <dholbach> ... which was screen-raping and broke whenever the HTML changed significantly
[14:30] <Q-FUNK> ok
[14:30] <dholbach> python-launchpadlib is the future and you need to "set it up" once
[14:32] <Q-FUNK> ok
[14:32] <Q-FUNK> well, now I know :)
[14:32] <Q-FUNK> has this been pushed into intrepid-updates too?
[14:33] <jpds> -backports
[14:35] <Q-FUNK> ok
[14:35] <Q-FUNK> anyhow, thanks for the pointers :)
[14:35] <jpds> No problem.
[14:41] <ScottK> Does is always use launchpadlib or just if you said you don't want to mail it in?
[14:42] <jpds> If you use mail, it doesn0t.
[14:43] <stefanlsd> dholbach: for the bugjam, can we use the 5-a-day stuff for teams like normal?
[14:43] <dholbach> stefanlsd: I plan to send out an announce about 5-a-day on wednesday - still hacking on a better, automatic solution :)
[14:44] <stefanlsd> dholbach: kk. :)
[14:44] <ScottK> jpds: Thanks
[14:45] <jpds> ScottK: It won't check for existing reports for the package though, just output a message saying it can't.
[14:48] <loic-m> Does anybody know what is the command to check in Ubuntu repositories : 1. what packages are built using a specific library?
[14:48] <loic-m> 2. What packages depend from a specific library/package?
[14:48] <jpds> apt-cache rdepends <package>?
[14:49] <persia> loic-m, apt-cache rdepends handles the second case.  For the first, you need to fiddle with grep-dctrol
[14:49] <ScottK> Or use reverse-build-depends in ubuntu-dev-tools
[14:51] <loic-m> Thanks persia / ScottK
[14:51] <loic-m> I guess it's too late to update xvidcore for Jaunty?
[14:52] <Laney> nope
[14:53] <Laney> depending on what the update is, you either have until the 19th or longer
[14:53] <loic-m> Laney: You think so? http://paste.ubuntu.com/118853/ lists a few apps
[14:54] <lidaobing> where can I find the release schedule for 9.04, such as the freeze time ...
[14:54] <Laney> loic-m: it all depends on what the update is
[14:54] <Laney> lidaobing: https://wiki.ubuntu.com/JauntyReleaseSchedule
[14:54] <Pici> !schedule-#ubuntu+1
[14:54] <Laney> excellent ubottu-fu
[14:55] <loic-m> Laney: going from 1.1.3, which is about 2 years old, to 1.2.1
[14:56] <loic-m> 2 years and 2 month actually
[14:56] <Laney> if you manage the transition then it's possible
[14:58] <loic-m> Laney: what does "manage the transition" mean? Rebuilding all the packages that depend on it and testing them?
[14:58] <lidaobing> Laney, thanks
[14:59] <slytherin> loic-m: as of now rebuilding should be fine, IMHO. Testing will occur eventually.
[15:00] <ScottK> jpds: I think the warning is a bit offputting for people not using lplib.  Couldn't it check if it was going to need the credentials before whining about it?
[15:00] <loic-m> Ok, I'll have a look then. There's already a bug and somebody offered a diff.gz (bug: #306399)
[15:01] <jpds> ScottK: I could do that, I'll look into it later.
[15:01] <stgraber> ScottK: hey, someone at work asked me to add unbound-control to the unbound package (universe), as you are the last uploader for it I just wanted to check with you if that was ok
[15:01] <ScottK> stgraber: Go for it.
[15:01] <stgraber> ScottK: ok
[15:01] <ScottK> jpds: Go for it.
[15:01] <ScottK> err.
[15:02] <ScottK> jpds: Thank you.
[15:03] <AndrewGee> Hey all. Any MOTUs available to review my package, gpxviewer? It's an application that allows users to look at GPS traces files in GPX format. Thanks :) http://revu.ubuntuwire.com/details.py?package=gpxviewer
[15:05] <jpds> ScottK: Done.
[15:05] <ScottK> jpds: Thanks.
[15:06] <bddebian> Heya gang
[15:07] <directhex> wotcha, bazza!
[15:12] <sven777> if I'm using a standard gnome icon in a .desktop file (e.g. Icon=utilities-terminal ) what is the correct dependency information I would need?
[15:14] <persia> sven777, You'd need to depend on the package providing that icon.  Ideally, there would be a virtual package that themes could Provide:, but I don't know that it exists today.  Maybe use lots of alternate dependencies for all GNOME flavours for now?
[15:15] <sven777> persia - what is the syntax for depending on (packageA OR packageB) ?
[15:17] <persia> sven777, Depends: packagea | packageb, packagec, libd
[15:17] <sven777> persia - thanks much
[15:17] <joaopinto> svaksha, that icon is probably provied by *-icon-theme, you will need to list hose
[15:17] <joaopinto> those
[15:18] <sven777> joaopinto: oh ok - thank you also :)
[15:18] <DktrKranz> hanska: FYI, evolution-sharp is now at 0.19.2, it fixes a build failure here.
[15:19] <hanska> DktrKranz: yes, someone in the team should give it some love
[15:19] <hanska> DktrKranz: maybe tonight :)
[15:20] <DktrKranz> hanska: heh! I'd like to merge your changes to (hopefully) finish gnome# transition, and I'd like to give you the due credit :)
[15:20] <hanska> DktrKranz: maybe tonight² :)
[15:20] <hanska> no, really, I'm studying now -- too busy to do mono work :)
[15:21] <hanska> (and, I'm also developing a Launchpad# library to access LP through its API :) )
[15:21] <DktrKranz> no rush, just FYI ;)
[15:23] <svaksha> joaopinto: ?
[15:23] <joaopinto> svaksha, was for sven777 sorry
[15:23] <svaksha> k :)
[15:31] <_16aR_> Hello
[15:36] <danielm> Can anyone take a look to: http://revu.ubuntuwire.com/p/thunar-shares-plugin ?. The package is pretty simple i think... and i corrected a few things
[15:38] <nhandler> danielm: I'll take a look
[15:40] <persia> danielm, Why do you require debhelper 7 and then use CDBS?
[15:42] <nhandler> danielm: In debian/copyright, don't use the full path to the .tar.gz. Just mention the website that you can download the .tar.gz from. You should also mention /usr/share/common-licenses/GPL-2
[15:42] <persia> nhandler, Why not use the full path in the copyright file?
[15:43] <persia> Is that just to save updating it for each new upstream?
[15:45] <nhandler> persia: Yes. Technically, it isn't wrong, it just is more work.
[15:47] <persia> nhandler, Makes sense.  I was just curious, as I usually don't pick on that unless it has the wrong URL.
[15:51] <nhandler> persia: I would rather get it changed now (at the initial packaging stage) than have to worry about remembering to update it for each new upstream release.
[15:52] <persia> My experience with UEHS is that most packages need a fairly thourough overhaul anyway.
[15:55] <nhandler> persia: That depends partly on how often upstream releases new versions and how often the Ubuntu package gets updated. If the Ubuntu package is updated pretty frequently, less changes need to be made.
[16:05] <loic-m> If an upstream tarball has a debian directory, I remove it, repackage it and mention that in the changelog, but do i need to write a get-orig-source rule?
[16:05] <danielm> nhandler: thanks for the review.. will fix it :)
[16:06] <Laney> loic-m: Yes, and a README.source
[16:06] <Laney> always if you repack
[16:07] <loic-m> Laney: thanks
[16:07] <Laney> btw, yes that is what I meant by managing the transition
[16:08] <Laney> ensuring that everything stays working
[16:08] <danielm> persia: what version should i use? 4?
[16:08] <loic-m> Well, the watch files doesn't work for example...
[16:08] <loic-m> Anybody know if MOTU Media Team still exist?
[16:08] <Laney> loic-m: So fix it, and ask upstream not to put the directory in their released tarballs
[16:09] <nhandler> danielm: 5
[16:09] <danielm> ok, thanks :)
[16:09] <nhandler> danielm: I'll do a more complete REVU later. I'm working on a patch right now.
[16:10] <Laney> dholbach: I think the "Busiest sponsors" thing on the HOF is misattributing me somehow. I've no way made 61 comments as a sponsor
[16:10] <nhandler> Laney: It isn't as a sponsor. It is 61 comments on LP
[16:10] <Laney> in that case I'm sure I've made more ;)
[16:10] <dholbach> Laney: comment on ubuntu-universe-sponsors
[16:11] <dholbach> comments
[16:11] <Laney> ah
[16:11] <dholbach> Laney: you sure have been busy :)
[16:11] <Laney> do you have the date of the comments?
[16:11] <dholbach> yes
[16:11] <dholbach> should be in the last 7 days
[16:11] <Laney> compare the date to the date of joining ubuntu-dev?
[16:11] <Laney> oh... hmm
[16:11] <Laney> anyway, yes I have been busy - the queue was quite large :)
[16:11] <dholbach> yes it was
[16:11] <dholbach> great work everybody
[16:12] <dholbach> I'm happy we're getting it in shape for feature freeze
[16:12] <persia> danielm, Generally, I recommend only using the version of debhelper you require for the features you want.  Also, if you're going to use debhelper 7, you may as well write a dh7 debian/rules
[16:13] <danielm> persia: i just used cdbs, because most of the thunar plugin are packaged using cdbs.. but i will take a look too
[16:13] <pinus> hi - anyone from MOTU Multimedia?
[16:14] <persia> danielm, In that case, you might just want to reduce the version of debhelper you require.  Check the debhelper changelog, and pick the oldest version that supports all the features you want.
[16:14] <persia> pinus, Best to just ask a question.
[16:14] <mok0> persia: he just did ;-)
[16:14] <ScottK> stgraber: Your unbound change is one that probably ought to be sent back to Debian (if you haven't already).
[16:15] <stgraber> ScottK: they don't have 1.2 yet IIRC
[16:15] <ScottK> stgraber: True.
[16:15] <ScottK> I'm guessing that'll change soonish.
[16:15] <danielm> persia: ok, and thanks for the review too.. :)
[16:16] <ScottK> stgraber: I'm a little uncertain about how much to feedback to them as the chroot by default change I did I know isn't suitable for Debian.
[16:17] <pinus> i just wonder when the vlc package is going to be upgraded
[16:18] <persia> pinus, For which release?
[16:19] <pinus> i use 8.10
[16:19] <persia> I don't think that vlc is planned to be upgraded.
[16:19] <persia> (but I'm not authoritative)
[16:20] <pinus> so, only in 9.4?
[16:20] <_16aR_> awesome ... I can't deinstall mysql-server-5.0 on my server ... bug in the postrm :(
[16:24] <directhex> nice. which release?
[16:24] <loic-m> I'm reading usacn man  page but I can't find a way to ask it not to try to dl the http page, and instead just check the packages in the directory
[16:24] <loic-m> Is there a way to do that in debian/watch?
[16:24] <sven777> I'm getting a lintian error about there being no specified debhelper version in my control file - but I state "debhelper (>= 5.0.51)" in it - can anyone tell me what is wrong with that syntax?
[16:25] <loic-m> upstream has a page http://www.xvid.org/Downloads.43.0.html but 1. with that name, it might change anytime (and I don't know the logic for the name) 2. the tarball are stored in http://www.xvid.org/downloads (but no web page)
[16:26] <_16aR_> directhex: 8.04
[16:26] <ScottK> _16aR_: You can get help in #ubuntu-server
[16:26] <_16aR_> it prompt me the debconf window to create the admin password
[16:26] <_16aR_> ok, thanks :)
[16:29] <persia> loic-m, I(d recommend scraping http://www.xvid.org/downloads/ : the don't-parse-the-page feature is better for ftp sites, or http sites with directory listing enabled.
[16:32] <loic-m> persia: how do I tell uscan to scrape a link? I can't find scrap* or parse in the man page
[16:33] <persia> loic-m, You use the two argument form, where the first is the page to scrape, and the second is the regex to match in the links on that page.
[16:35] <persia> loic-m, Search the uscan manpage for "lukasl"
[16:35] <loic-m> persia: http://www.xvid.org/downloads/ has no links, there's no web page. Do you mean using http://www.xvid.org/Downloads.43.0.html first?
[16:35] <persia> loic-m, I get a page when I use that URL.
[16:37] <loic-m> persia: right, sorry, I was using links from the site, not the right link
[16:37] <persia> loic-m, Oh, I see.  That's just unpleasant.  You probably can't write a working watch file.
[16:37] <persia> You may as well write one scraping http://www.xvid.org/Downloads.43.0.html but I wouldn't be surprised if it never reported an update.
[16:38] <loic-m> persia: indeed, I'll try
[16:38] <persia> You should explain this to upstream, and indicate that this is why Ubuntu hasn't updated recently, and ask them to make a sensible download page with all their releases available.
[16:41] <loic-m> persia: I'll do that. In the meantime, will the update be possible in Jaunty if there's no watch file anymore?
[16:42] <persia> loic-m, That's why I suggest making a watch file scraping the Downloads.43.0.html page: this will make it easier for the uploader.
[16:42] <persia> It just won't track the new upstreams.
[16:43] <sven777> nm - I think I figured it out - I didn't realize "compat" was still at 7
[16:43] <persia> Anyway, we only use watch files to update packages in development releases, and generally only before FeatureFreeze.  Other updates tend to require manual attention.
[16:46] <loic-m> persia: if I understand correctly, I drop the watch file, and if/when the package is accepted Ubuntu archive admin pick the tarball manually on the website?
[16:48] <persia> loic-m, Nope.
[16:48] <persia> You have a watch file in your diff.gz that gets the version you are targeting.  The uploader uses that watch file to get the orig.tar.gz and uploads it.  The archive-admin usually has no involvement.
[16:49] <Laibsch> Has anybody managed to set up pbuilder for building against Debian unstable?
[16:49] <directhex> trivially
[16:49] <Laibsch> Not here, following https://wiki.ubuntu.com/PbuilderHowto
[16:50] <Laibsch> I can create a pbuilder environment for hardy and intrepid as well as lenny
[16:50] <Laibsch> but not jaunty or unstable
[16:50] <Laibsch> directhex: Can you share what you did?
[16:50] <directhex> the pbuilderrc example on the very page you linked to handles debian as well as ubuntu
[16:51] <Laibsch> http://rafb.net/p/mcLRSw25.html
[16:51] <Laibsch> directhex: in theory
[16:51] <Laibsch> for me only lenny
[16:51] <Laney> pbuilder-dist is where it's at
[16:52] <nhandler> Laibsch: Do you have backports enabled?
[16:52] <directhex> your debootstrap is obsolete then
[16:52] <Laibsch> nhandler: no
[16:52] <nhandler> Laibsch: That is your problem. You need the packages from backports for this to work
[16:53] <Laibsch> OK, thanks for pointing that out
[16:53] <Laibsch> Not so trivial if the page is missing an important piece of info
[16:53] <loic-m> persia: ok, so i still need to write a watch file, and I'm back to square one. How do I tell uscan to dl the file without trying to find the link on a web page?
[16:53] <nhandler> Laibsch: Feel free to add a note about that.
[16:54] <Laibsch> Laney: Thank you for the hint
[16:54] <Laibsch> do you use pdebuild with pbuilder-dist?
[16:55] <Laney> nope
[16:55] <Laney> is pdebuild like debuild -S and pbuilder build in one?
[16:55] <loic-m> persia: (the lkasl method doesn't work, and I'm lost)
[16:55] <nhandler> Laney: pdebuild accepts most of the options as debuild
[16:56] <Laney> what does it do differently?
[16:56] <nhandler> So you can do pdebuild -S or pdebuild -S -sa
[16:58] <Laibsch> Laney: basically, debuild -S and pbuilder in a single step, I guess, yes
[16:58] <RainCT> heya
[16:58] <Laibsch> nhandler: done
[16:58] <Laibsch> although I'm the one the least qualified to do that
[16:59] <Laibsch> which is why you now the page has a big X where it did not have the necessary info
[16:59] <RainCT> «There are currently 95 different tags in use. The most popular of them is being used 21 times.» wow
[16:59] <RainCT> mok0, I see you liked them :P
[16:59] <mok0> RainCT: Err what?
[16:59]  * mok0 is confused
[17:00] <nhandler> mok0: you have been doing a lot of tagging on REVU
[17:00] <RainCT> mok0: that you've tagged lots of stuff :)    (only someone else also got on tagging spree)
[17:00] <mok0> Ah, yes :-)
[17:00] <persia> loic-m, It works for me.
[17:00] <mok0> Yes they are very nice, /me likes
[17:00] <RainCT> :D
[17:00] <RainCT> ok, I'll add a search form now so that nhandler is also happy :)
[17:00] <persia> loic-m, http://paste.ubuntu.com/118883/
[17:01] <mok0> RainCT: and add the rungs to make /me happy...
[17:01] <nhandler> RainCT: :D
[17:01] <RainCT> mok0: if someone answered your thread on the ML..
[17:01] <persia> loic-m, Now, how does that differ from your watch file?
[17:01] <mok0> I think we need another MOTU meeting
[17:02] <RainCT> master persia, what do you think about mok0's proposal? :P
[17:02] <RainCT> but do the next one a few hours later, please
[17:03] <persia> RainCT, Looking now.
[17:04] <persia> Anyone feel like handling bug #267472?  Seems we've been ignoring this package for a year or so.
[17:05] <nhandler> persia: I'll take a look
[17:05] <persia> nhandler, Cool.  Ought be a simple enough update, but I don't envy the user who has been looking for us to release with the latest version since Hardy :)
[17:05] <loic-m> persia: thanks a lot, I hadn't understood you could use an absolute path and was using files/xvidcore-([\d\.]*)\.tar\.gz
[17:06] <persia> mok0, I get a MOD_PYTHON ERROR when I try to look at your page.
[17:06] <mok0> persia: index page?
[17:06] <persia> loic-m, You in fact have to use a regex that matches, so while I used the absolute path, some people use .* to ignore most of it.
[17:06] <persia> mok0, http://dmz-212.daimi.au.dk/~mok/revu/
[17:07] <Laibsch> man, this sucks.  The exact example from the man page does not work. nothing works: http://rafb.net/p/vBuLJw91.html
[17:07] <mok0> oh dear
[17:07] <Laney> what happened with the MC vote?
[17:07] <mok0> Ah, a merge residual
[17:07] <nhandler> Wasn't is meant to be this past week?
[17:07] <persia> Laney, We're waiting for the TB & CC to select a shortlist from amoung the nominees.
[17:08] <Laney> Interesting, I didn't know about that step
[17:08] <persia> nhandler, Ideally, yes.  We lose a member on Friday, which makes us short.  Given that there's usually one or two of us missing at any given time of day, that gets tight.
[17:08] <persia> Laney, https://wiki.ubuntu.com/CommunityCouncil/Delegation
[17:09] <Laney> hmm
[17:09] <Laney> "will determine a shortlist" is a bit vague
[17:10] <mneptok> persia: ahoy matey
[17:10] <persia> mneptok, avast
[17:10] <mneptok> persia: how goes hte struggle?
[17:11] <mok0> persia: try again
[17:15] <persia> mneptok, Two days to Feature Freeze, 81 packages on UEHS, 49K in MoM/universe.html, over a hundred unreviewed packages on REVU, 100 bugs in the sponsors queue, we got a full tank of gas, half a pack of cigarettes, it's dark, and we're wearing sunglasses.
[17:16] <Laibsch> Is pbuilder-dist supposed to work on a stock hardy? http://rafb.net/p/vBuLJw91.html
[17:16] <mneptok> persia: DON'T SLOW DOWN! THIS IS BAT COUNTRY!
[17:17] <mneptok> hmmm ... you know, i'm not sure i like mixing Huinter S Thompson and Blues Brothers references.
[17:17] <mneptok> seems *really* dangerous
[17:18] <persia> mok0, Working now, thanks.
[17:18] <mok0> persia: only the listings work, nothing else
[17:19] <persia> I still don't like it.  I think it 1) makes it harder for people picking up abandoned packages, 2) makes it harder to find an interesting package by name, 3) and generally adds unecessary complexity to the view.
[17:19] <geser> Laibsch: have you pbuilder from hardy-backports?
[17:19] <nhandler> persia: bitpim has 1.0.6.dfsg.1-1 in Experimental. Would it be better to merge this version first to get the Ubuntu package in sync with the Debian one?
[17:19] <persia> That said, by current rates of change, I'm about to stop being the primary REVUer, so your opinion may soon weigh more than mine.
[17:20] <Laibsch> geser: no, but if pbuilder from stock hardy doesn't work, maybe it should get pulled?  or updated?
[17:20] <persia> nhandler, I'd probably only do one upload, but yes, I'd think the right procedure would be to merge and then update.
[17:21] <geser> Laibsch: define "work", of course pbuilder from stock hardy doesn't know about the new versions, but besides this it works fine
[17:21] <RainCT> Laibsch: you need to install some package (don't remember which) from -backports so that your system knows about intrepid
[17:21] <sven777> would a MOTU be so kind as to review my package?  (It already has one advocate.) Thanks in advance!  http://revu.ubuntuwire.com/p/lmalinux
[17:21] <persia> mok0, Additionally, because things don't requeue on upload, it means someone has to poke someone directly for a reupload after archive-admin rejection.
[17:21] <mok0> persia: 1) don't know what you mean there. 2) on the contrary, easier, because the list is shorter 3) complexity? The lists are shorter
[17:22] <persia> mok0, 1) Often I see people talking about packaging someting, and point them at REVU, and they are excited to discover the work half done by someone else who abandoned it.
[17:22] <mok0> persia: they do requeue, in the needs-review section
[17:22] <mok0> persia: 1) no different from now
[17:22] <persia> mok0, 2) I disagree: I have to check more lists to find a package by name, and can't just use find in my browser.  That makes the interface less good.
[17:23] <persia> Well, except that one can't use the browser search.
[17:23] <mok0> persia: RainCT is adding a search feature
[17:23] <persia> Which means more page loads.  That doesn't help, especially if I want to browse, rather than search.
[17:23] <RainCT> .. and with the current filter system you will still be able to get complete lists
[17:23] <mok0> persia: plus, the path is simple now, it's just /p/packagename
[17:23] <persia> (which is usually the case).
[17:23] <RainCT> mok0: the rung stuff would need to be merged with the new changes, btw :P
[17:24] <mok0> RainCT: yea
[17:24] <persia> RainCT, That's interesting: the demo doesn't show it as filters.
[17:24] <mok0> persia: that's because it's not implemented in the copy
[17:24] <RainCT> persia: filters are something now I added this last weekend :)
[17:24] <persia> mok0, Ah, the requeuing there seems sane.
[17:25] <nhandler> persia: What do you think about my idea about having the home page allow each user to specify one or more "searches" to be performed.
[17:25] <mok0> persia: in the entry queue (Unreviewed) and exit queue there is no requeing
[17:25] <AdamDH> whats the best way to find build dependancies a package requires?
[17:25] <persia> 3) complexity in that there are more screens to visit: the lists may be shorter, but my effort to find something is greater (although being able to turn off the filters may address this).
[17:25] <RainCT> persia: you can currently filter for: archived/unarchived/both, new/updated/both, with tag, without tag, commented on by user, package name contains
[17:25] <persia> RainCT, Great.  Can I turn off filtering, and get one big list, sorted by status?
[17:25] <Laibsch> geser: hardy is still supported (without backports).  It should eventually be taught about intrepid and jaunty.  Does "pbuilder-dist unstable create" work for you?  Unstable has been around long enough.
[17:26] <persia> nhandler, I'm not sure I understand in sufficient detail.
[17:26] <mok0> persia: there's a tradeoff with the advantages of the packages follow a graduating path
[17:26] <RainCT> persia: there'd be a rung=any option or something like that
[17:26] <persia> mok0, I fail to see any advantages.
[17:26] <persia> RainCT, And I could set that by default in my preferences?
[17:26] <RainCT> could be done
[17:27] <persia> mok0, Note that my failure to see any advantages doesn't mean you don't get an advantage.
[17:27] <mok0> persia: heh
[17:27] <persia> I don't mean to say it's better how it is, only that it's better *for me* how it is.
[17:27] <nhandler> persia: For instance: I would be able to specify that I want to see lists of packages that already have one advocation, the 5 newest uploads to revu, packages tagged with the perl tag, and packages with plasma-widget in their name. All of these would be searches, and they would all show up in their own "list" on revu
[17:27]  * RainCT is indifferent to mok0's proposal, btw
[17:27]  * mok0 cries
[17:28]  * RainCT hugs mok0 :)
[17:28] <mok0> :-)
[17:28] <persia> nhandler, That wouldn't be useful to me, as I very rarely want packages of a given language, or in a given state.  The exception is that when I'm annoyed, I'm more likely to look at previously advocated packages to reject them due to licensing or some such.
[17:28] <RainCT> lol
[17:29]  * RainCT wouldn't have expected this from persia :)
[17:29] <mok0> RainCT: I suppose you can generate the "old style" view by showing packages of rung 0,1,2 & 3
[17:29] <geser> sven777: your package FTBFS and as I see you have a rules file, you might want to check where the correct path is now as the other rules live in /lib/udev/rules.d (and check also the sequence number)
[17:29] <nhandler> persia: Well, the beauty of this idea would be that each user could custimize which searches they want to be shown on the main revu page for them. So you could have a list of all the packages on REVU if you want.
[17:29] <persia> And I argue that the 5-most-recent is actually counterproductive in terms of reducing average latency.  One of the reasons I don't argue more strenuously against mok0's proposal is that he is doing most of the REVU right now, and I admire both the work and the effort to reduce average latency.
[17:30] <RainCT> mok0: right. actually, there could be an option, like persia suggested, to choose between old/new style. I'll leave this for you *g*
[17:30] <persia> nhandler, Yes, but I'd rather pick some defaults that make sense for heavy REVUers, and optimise for workflows that achieve certain social benefits.
[17:30] <mok0> RainCT: OK I'll take a look
[17:31] <RainCT> oh.. saving searches into the menu would also be an option
[17:31] <nhandler> RainCT: Cool
[17:31] <persia> RainCT, What would that cost in terms of CPU time?  spooky isn't the fastest machine.
[17:32] <geser> Laibsch: if pbuilder-dist doesn't work for unstable than please file a bug, but I don't know if adding support for intrepid and jaunty warrants a SRU of pbuilder
[17:32] <tgm4883> Can I please get a second ack/revu on http://revu.ubuntuwire.com/p/mythnettv
[17:32] <sven777> geser : I am using pbuilder for jaunty and intrepid and it built for me - how are you building it?
[17:32] <RainCT> persia: one additional SQL query per page load
[17:32] <geser> sven777: jaunty pbuilder on amd64
[17:32] <mok0> Oh, amazon dispatched my new book on Objective C :-)
[17:32] <persia> RainCT, And probably nothing like the current monster query.  Sounds sane.
[17:33] <sven777> geser - that's what I used as well - what error are you getting?
[17:33] <Laibsch> geser: Does "pbuilder-dist unstable create" work for you?
[17:33] <RainCT> persia: nope, just fetching the list of saved "shortcuts" for the logged in user
[17:34] <RainCT> persia: ah, have you seen that I've fixed the cookie now? :)
[17:34] <persia> RainCT, I did.  I haven't had to log in for a while.  I appreciate that, especially given how often my browser crashes (I probably shouldn't save my stack by having that many windows/tabs open)
[17:35] <loic-m> With the new copyright format http://wiki.debian.org/Proposals/CopyrightFormat do we need to paste the text of the GPL2 for each file that is licensed against the GPL2
[17:35] <RainCT> loic-m: yep
[17:35] <persia> loic-m, Nope.  You have Files: sections and License: sections.
[17:35] <RainCT> heh
[17:35] <persia> You can have multiple files per Files: section, and you can reference common licenses.
[17:35] <loic-m> or is it possible to assign the copyright to all the files one by one, then use a License at the end (all the files have GPL2, but different authors)?
[17:36] <RainCT> at least that's how I've always seen it, having the GPL header after the "License: GPLx" line
[17:36] <persia> RainCT, You and I seem to have differing interpretations.  Let's both read it again :)
[17:36] <loic-m> persia: so I assign the © to files, and after I've listed all of them I put a line LICENSE ?
[17:36] <mok0> I believe you paste those 3 GPL paragraphs the first time you reference it
[17:36] <geser> Laibsch: no, looks like debootstrap doesn't know about unstable (I don't know if it's a bug or on purpose)
[17:36] <loic-m> pasting the LICENSE each times would double the package size ;)
[17:36] <RainCT> ahh
[17:36] <mok0> persia: I side with RainCT on this one
[17:37] <RainCT> I think I misunderstood the question :P
[17:37] <mok0> loic-m: only the first time
[17:37] <Laney> Laibsch: it calls it sid afaik
[17:37] <persia> RainCT, I think you can do it that way, or use standalone License sections.
[17:37] <loic-m> mok0: so each fils Copyright/License, but only the first one do I paste the GPL2 License text?
[17:37] <persia> mok0, On which ?
[17:37] <loic-m> s/fils/files/
[17:38] <RainCT> loic-m: yep
[17:38] <persia> loic-m, Each Files: section can reference multiple files.
[17:38] <mok0> If you have several sections that reference the same license, you only need the clause the 1st time
[17:38] <RainCT> loic-m: and you can use * as wildcard in File:
[17:38] <mok0> o
[17:39] <loic-m> persia: each file has a different set of authors. It's like with 7 authors or so you'd get many, many possibilities
[17:39] <persia> loic-m, You must include licensing for each Files: section, bt that can either be the text of the license, or reference a standalone License section.
[17:39] <geser> sven777: cp: cannot create regular file `/tmp/buildd/lmalinux-0.8.1/debian/lmalinux/etc/udev/rules.d': No such file or directory
[17:39] <c_korn> do you also review packages from PPA or do I have to upload them to http://revu.ubuntuwire.com ?
[17:39] <persia> mok0, I completely disagree: you need to include it *each* time if you do it embedded: if you want to only do it once, you need to use a standlone License: header.
[17:39] <loic-m> I'll have a go, then pastebin when I've got something that looks sane enough
[17:39] <persia> loic-m, You get lots of variance for Copyright: , but probably less so for License:
[17:39] <nhandler> c_korn: You need to upload to REVU
[17:40] <mok0> persia: hm, the document seems to have evolved quite a bit since I last read it
[17:40] <persia> Well, strictly speaking, there's no requirement to use REVU for package review, but most people use it, and it's easier for the reviewer.
[17:40] <c_korn> (it is an update of a package that is already in the repositories)
[17:40] <nhandler> c_korn: Then just file a bug on LP and attach the .diff.gz
[17:40] <persia> mok0, Yes.  I re-read it today for other reasons.  It did once require that level of repitition.
[17:41] <c_korn> nhandler: ok, the bug report already exists: https://bugs.launchpad.net/debian/+source/scilab/+bug/272264
[17:41] <nhandler> c_korn: I don't think we sync from PPAs
[17:41] <persia> It's certainly non-trivial to sync from a PPA.  Better to have a fresh upload until the tools change.
[17:42] <c_korn> ok
[17:44] <sven777> geser - so in jaunty the location of the udev rules has moved to /lib/udev/rules.d  ?
[17:45] <RainCT> c_korn: http://revu.ubuntuwire.com/import.py
[17:46] <persia> sven777, Consider using dh_installudev
[17:46] <persia> RainCT, for a package update?
[17:46] <sven777> persia - ah I wasn't aware of that helper - thx :)
[17:47] <RainCT> ah, no. I missed the message that it's an update
[17:47] <persia> sven777, I don't promise it does the right thing, but if it doesn't, that's a bigger bug, and worth fixing outside your package: you shouldn't have to care how udev stores the rules.
[17:48] <c_korn> RainCT: thanks
[17:50] <nhandler> persia: It looks like 1.0.6 is the latest release from upstream: http://bitpim.svn.sourceforge.net/viewvc/bitpim/releases/.
[17:51] <persia> nhandler, Odd.  I wonder why the submitter was looking for 1.0.7.  Thanks for checking: I guess it's just a merge.
[17:52] <nhandler> persia: They might have a 1.0.7 under development, but 1.0.6 is the latest release. I'll add a comment to the bug and merge from Experimental
[17:53] <persia> "BitPim Test release 1.0.7.20081215 is available." from www.bitpim.org.
[17:53] <persia> I suspect it's someone with versionitis.
[17:54] <nhandler> I don't think it is worth going to 1.0.7 while it is a test release. Especially since 1.0.6 is in Debian
[17:54] <geser> sven777: looks like it, I don't know where package should install there own files
[17:55] <persia> I agree, unless someone who cares wants to coordinate scheduling with upstream.
[17:55] <persia> I don't think either of us fall into that category :)
[17:55] <nhandler> Very true persia ;)
[17:57]  * slytherin hopelessly watches the painfully slow build of fop. :-(
[17:59] <c_korn> slytherin: the PPA build took 14 minutes: https://launchpad.net/~getdeb.packages/+archive/ppa/+build/859967
[18:00] <slytherin> c_korn: I am building it on my ibook (powerpc). That is why it is slow.
[18:00] <c_korn> ok
[18:04] <loic-m>  Is there a tool to extract Copyrights from multiple source files in order to simplify debian/copyright writing?
[18:04] <persia> licensecheck can help some.
[18:05] <persia> (it is not a panacea)
[18:06] <loic-m> thanks
[18:06] <quadrispro> superm1: I read your mail, so, do you think it's necessary upload it to REVU? I think not...
[18:08] <persia> quadrispro, Without context, I could be wrong, but it's considered best practice for every new package to have been reviewed by two developers.  REVU is a tool for this, but not a necessity.  If you've already reviewed with someone else, there's little point.  If not, it can help.
[18:08] <loic-m> Oh, licensecheck --copyright only extract lines with the word copyright, which means it doesn't work since there's multiple copyrights for each files (and only "copyright" on the first line...)
[18:08] <quadrispro> persia: Hi Emmet, we're talink about w-scan, which is waiting in debian NEW
[18:09] <quadrispro> s/talink/talking
[18:10] <persia> quadrispro, My general advice for packages from NEW is that it should get review by someone not the uploader to Debian before being committed.  That can be an ftp-master, or an Ubuntu Developer.
[18:10] <persia> REVU is probably overkill, but one way to do that.
[18:10] <quadrispro> ok, I'm uploading to REVU now, thank you!
[18:11] <persia> quadrispro, Feel free to advocate your uploads now: it only takes one other developer.
[18:11] <Laibsch> Laney: thanks, sid does indeed work
[18:11] <maxb> Wasn't w-scan already in revu?
[18:11] <quadrispro> yes, I know
[18:14] <quadrispro> maxb: yes but Tobias Grimm worked on it sometime ago -> http://svn.debian.org/wsvn/pkg-vdr-dvb/dvb/w-scan/trunk/
[18:14] <quadrispro> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426390
[18:14] <loic-m> Can MOTU have a look at the beginning of the copyright file at http://paste.ubuntu.com/118904/ and tel me if there's things I'm doing wrong?
[18:15] <RainCT> loic-m: I think you're using an old revision
[18:15] <RainCT> (in the URL)
[18:15] <superm1> quadrispro, aren't you a MOTU now? :)  go ahead and look it over for any problems and then you should  be able to upload it to Ubuntu NEW provided you see nothing wrong
[18:16] <Laney> Laibsch: cool
[18:16] <RainCT> loic-m: add the "see /usr/share/common-licenses.." stuff to the GPL header
[18:16] <quadrispro> superm1: ehm.. persia said that could be better uploading to REVU before :)
[18:16] <persia> quadrispro, Indeed: my apologies for any confusion: if you aren't the Debian uploader, just upload it.
[18:17] <RainCT> loic-m: and I think it's only one space indentation.. looks fine otherwise
[18:17] <quadrispro> ok! I'm going to do it now
[18:17] <persia> The point is that new packages ought get looked at by two people, because we all make mistakes.
[18:17] <tgm4883> knock knock
[18:17] <RainCT> loic-m: (Upstream-Source could be a link to the download page)
[18:17] <persia> loic-m, That doesn't match my reading of the format at all.
[18:18] <persia> loic-m, By my reading, you either need to include the license header for *every* stanza, or have a Standalone License: section at the bottom with the header.
[18:18] <loic-m> RainCT: I'll correct the revision
[18:18] <loic-m> RainCT space indentation - are you talking about the GPL2 text? Yes, too much spaces - however shouldn't that be 2 spaces?
[18:19] <RainCT> loic-m: not sure
[18:19] <persia> Hmm.  Looking at that, I wonder if licensecheck could be extended to draft an intitial debian/copyright given a source tree.
[18:19] <RainCT> that'd be nice
[18:19] <persia> It would make mistakes, but it means we're down to only debian/control that isn't automatable.
[18:19] <RainCT> loic-m: you're also missing copyright for debian/*
[18:20] <directhex> persia, using the copyright format proposal? woo
[18:20] <loic-m> persia: Upstream-Source dl page I'm not sure they're not moving their dl pages around, so I kept it simple
[18:20] <Laney> Similarly, there could be a nice copyright reviewing tool
[18:21] <Laney> Parse the machine-readbable copyright format and display the corresponding licensecheck output with it
[18:21] <Laney> to see if the two match up
[18:21] <loic-m> RainCT that's only the beginning. There's like ten times more files in src/
[18:21] <persia> directhex, Yeah.  I'm reminded of the oft-discussed idea of writing a script that helps make a package mostly right the first time.  With debhelper 7, debian/rules can just be stubbed, and usually kinda works.  dch --create does debian/changelog.  The new format might allow for fairly simple stub for debian/copyright that just needs a little editing.  debian/control is still tricky.
[18:21] <persia> Laney, Indeed.  Feel like scripting something?
[18:21] <Laney> persia: I will once we get a libdebiancopyright
[18:22] <RainCT> Laney: what's that?
[18:22] <directhex> -cil
[18:22] <directhex> :p
[18:22] <Laney> RainCT: Use your imagination
[18:22] <Laney> directhex: you can write the bindings!
[18:22] <RainCT> ^^
[18:22]  * RainCT poweroffs directhex 
[18:22] <persia> Laney, Is one in the works?
[18:22] <Laney> I would imagine so
[18:23] <Laney> (but that is just supposition)
[18:23] <persia> You could kickstart it ...
[18:23] <directhex> Laney, bindings? haven't you been reading your tinfoil hat blogs? the plan is to replace native libs with managed libs!
[18:23]  * Laney runs away swiftly
[18:23] <directhex> see: ndesk dbus!
[18:23]  * Laney looks at ipod-sharp
[18:23]  * Laney shakes fist
[18:24]  * directhex looks at fist
[18:24]  * directhex shakes ipod-sharp
[18:25] <Laney> *** A level 10 Steve Jobs fell out! It must be your lucky day!
[18:25] <loic-m> persia: I've checked Standalone License Section and i'll think I'll go with that
[18:25]  * slytherin plans to infest mono with some java code.
[18:26] <directhex> slytherin, what was that? did i hear you volunteering to maintain ikvm? ;)
[18:26] <Laney> j#!
[18:26] <loic-m> 2 other questions: 1. "Files: src/bitstream/mbcoding.c, src/bitstream/mbcoding.h, src/bitstream/vlc_codes.h" is that ok? or Files: src/bitstream/mbcoding.c, mbcoding.h, vlc_codes.h ?
[18:26] <slytherin> directhex: sure. is it ready to replace jvm on powerpc? :-)
[18:26] <directhex> slytherin, for non-gui apps, i'd love to hear test results
[18:27] <persia> loic-m, I'd go either with the former, or with regexes: you want this to be machine readable.
[18:27] <loic-m> 2. I'm separating files with an empty line so it's more easy to parse, is that ok?
[18:27] <persia> Check the BNF for the format (on the wiki page).
[18:28] <Laney> maybe to parse by a human, to a machine it probably wouldn't matter
[18:28] <loic-m> persia: so the former is ok ( src/bitstream/mbcoding.c, src/bitstream/mbcoding.h with a space bw?)
[18:28] <directhex> slytherin, though i'm accepting no responsibility pre-jaunty
[18:28]  * persia checks the BNF
[18:30] <_16aR_> any REVU admin ?
[18:30] <nhandler> _16aR_: What's up?
[18:30] <_16aR_> I've updated a package with dput -f, but the upload doesn't show :/
[18:30] <jpds> _16aR_: HI.
[18:30] <nhandler> _16aR_: What package
[18:30] <persia> loic-m, I think you're not supposed to use blank lines.  Also, I don't see any examples of multiple files in a Files: section without a wildcard.  I'm not sure how to advise you.
[18:30] <_16aR_> box2d
[18:31] <nhandler> And when did you upload it?
[18:31] <jpds> _16aR_: Not in the rejected or upload queue.
[18:31] <_16aR_> about 2 hours ago
[18:31] <nhandler> _16aR_: http://revu.ubuntuwire.com/p/box2d
[18:31] <loic-m> persia: without blank lines it's a pain to create and a pain to check (for a human) :(, but I can remove them when I'm done.
[18:31] <_16aR_> nhandler: yes
[18:31] <c_korn> someone has put jeuclid into that jeunty queue: https://launchpad.net/ubuntu/jaunty/+queue do I also have to setup a revu?
[18:31] <persia> loic-m, Fair.
[18:31] <_16aR_> the last upload I see is a 1h42
[18:32] <nhandler> _16aR_: Try uploading again
[18:32] <_16aR_> ok
[18:32] <slytherin> c_korn: for what?
[18:32] <persia> c_korn, If it's already in the queue, it's pending review by the archive-admins.  No point uploading to REVU.
[18:34] <persia> c_korn, In fact, it appears to be your version of jeuclid in the queue.
[18:35] <_16aR_> nhandler: done :)
[18:35] <_16aR_> Maybe one problem come from the fact that my mail server is down ?
[18:37] <nhandler> _16aR_: It doesn't use your mail server
[18:38] <persia> _16aR_, What is the relationship between your package and http://svn.debian.org/wsvn/pkg-games/packages/trunk/box2d/?rev=0&sc=0
[18:40] <c_korn> persia, slytherin: yes it is my version. just asked because I am new to this package releasing stuff
[18:40] <c_korn> slytherin: fop still compiling?
[18:40] <slytherin> c_korn: No. It is done. acked the sync bug.
[18:41] <persia> c_korn, Basically, when something is ready, it gets uploaded.  When it's a new package, it's a good idea to have two people look at it, because we all make simple mistakes.  REVU is the tool we use for that.
[18:42] <_16aR_> hmmmmm .... That's the same in fact :p
[18:42] <persia> Because some people who prepare packages are very unfamiliar with best practices, we like that to be two developers.
[18:42] <_16aR_> the same upstream
[18:42] <_16aR_> ah no
[18:42] <_16aR_> not the same upstream
[18:43] <_16aR_> I use the upstream with cmake
[18:43] <persia> No?  Then you might want a different name for your package, as we'll expect to sync that for jaunty+1.
[18:44] <_16aR_> ok
[18:44] <c_korn> slytherin: I just got the mail. thank you
[18:44] <persia> Or if the contents aren't different, you'll want to coordinate with the Debian Games team to develop a common solution.
[18:44] <_16aR_> then I add +cmake suffix ?
[18:44] <persia> It's significantly less than ideal to have differing orig.tar.gz files, because it makes it hard to merge or sync.
[18:45] <_16aR_> Yes
[18:45] <persia> So please don't do that :)
[18:45] <_16aR_> Otherwise it can ben retrieved on the svn
[18:46] <_16aR_> so what can I do ?
[18:46] <_16aR_> the cmake version facilitate² the packaging work
[18:46] <persia> I'd recommend working with the Debian Games team to determine a common solution, and get that uploaded into squeeze, and Ubuntu will sync in Jaunty+1
[18:46] <persia> Because it's a library with no clients, it's hard to support as something that needs to be in place before feature freeze.
[18:46] <_16aR_> so no possible to have it for jaunty ? :(
[18:47] <persia> How is it useful for Jaunty?
[18:47] <_16aR_> to have numptyphysics in it too ;)
[18:47] <persia> (and it's at the bottom of a *long* queue, so it's unlikely anyway).
[18:48] <persia> And you expect both of these can be ready and uploaded in two days?
[18:48] <_16aR_> I may be too much optimistic, but I have time :p
[18:49] <persia> OK.  Good luck.  If it doesn't work out, get in touch with the Debian Games folk, and get it into Squeeze.
[18:49] <bmhm> hi all. How do i move manpages and docs to a <pkgname>-doc-package and header files to a -dev - package?
[18:49] <_16aR_> ok :)
[18:49] <_16aR_> but since the upload doesn't work, I think I can't do it :)
[18:49] <persia> bmhm, The common way is to use dh_install
[18:49] <_16aR_> my upload doesn't show :(
[18:50] <bmhm> persia: i wondered but it is not mentioned explicitly in https://wiki.ubuntu.com/PackagingGuide/Complete
[18:50] <persia> bmhm, The EXAMPLE section of the dh_install manpage describes just such an arrangement.
[18:50] <_16aR_> bmhm: use .install, .docs, .manpage files
[18:51] <persia> bmhm, Also, "Complete" isn't really the right description for that guide :)
[18:51] <_16aR_> nhandler: do you see my upload ?
[18:51] <bmhm> I see ;-) thanks for the info
[18:52] <persia> bmhm, No problem.  Feel free to ask any questions here: we might point you at documentation rather than explaining things, but we're always happy to help.
[18:53] <bmhm> yeah, thats very ok for me
[18:53] <bmhm> you should see ubuntu-de, they are always laughing at newbies and only few did really help
[18:53] <slytherin> Juli_: around?
[18:54] <bmhm> like some1 asking for a good html/php IDE. They said "vim". When he asked for a _graphical_ IDE for X then, they told him to use "gvim". He was very upset and such things do happen very often in #ubuntu-de
[18:55] <bmhm> that's really sad
[18:56] <RainCT> :/
[18:56] <_16aR_> bmhm: the worst on ubuntu-de : they speak german !
[18:56] <_16aR_> ^^'
[18:56] <_16aR_> <= kick me :p
[18:56] <persia> bmhm, I suspect the difference is that we expect you're going to help us take care of the packages, so since you're making it easier for us, we may as well make it easier for you.  User support forums are a little different, although it's sad to hear such strong antagonism.
[18:57] <james_w> jelmer: some comments on http://revu.ubuntuwire.com/p/evolution-mapi
[18:57] <bmhm> yeah you're right
[18:57] <_16aR_> for good php/IDE, i don't if it better now, but you can have a look at eclipse :p
[18:57] <_16aR_> 3/4 years ago, it wasn't awesome, but maybe it is cool now
[18:57] <bmhm> Well at the moment I am building packages for gnome-globalmenu, but I hope they might eventually end up in MOTU
[18:58] <_16aR_> nhandler: ? are you here ? :D
[18:58] <_16aR_> my upload still doesn't show in revu :(
[18:59] <nhandler> _16aR_: What command are you using to upload it?
[19:01] <_16aR_> dput -f revu changefile.changes
[19:01] <RainCT> james_w: hehe I thought that one would come :)
[19:01] <james_w> RainCT: why's that?
[19:02] <RainCT> I mean bug #330191 :)
[19:02] <james_w> RainCT: ah :-)
[19:02] <james_w> the rest of the change is good though
[19:03] <jelmer> james_w, thanks!
[19:03] <jelmer> james_w, also for the bzr-builddeb merges
[19:03] <james_w> jelmer: bzr-fastimport as well, which looks pretty good
[19:03] <james_w> jelmer: thank you, there was some good stuff there
[19:03] <slytherin> _16aR_: You are uploading sources.changes file right?
[19:04] <_16aR_> yes
[19:05] <_16aR_> I build with pbuilder, so no mix
[19:06] <slytherin> _16aR_: can you type complete command you used?
[19:07] <_16aR_>  dput -f revu ../box2d_2.0.1-0ubuntu1_source.changes
[19:07] <slytherin> persia: need to discuss netbeans packages. Any idea why do they keep adding version in the binary name libnb-platform-java?
[19:07] <_16aR_> from the source root directory (where I type debuild -S -sa)
[19:07] <slytherin> _16aR_: can you paste the output of the command somewhere?
[19:08] <_16aR_> yes
[19:08] <_16aR_> http://paste.ubuntu.com/118912/
[19:08] <_16aR_> slytherin:
[19:08] <bmhm> what I like about debian-based systems are the .deb-packages. RPM is really annoying. Good decision. :-)
[19:09] <_16aR_> .deb > .rpm
[19:09] <bmhm> :-)
[19:09] <_16aR_> but the lsb is about rpm :(
[19:09] <bmhm> yeah I know
[19:09] <_16aR_> didn't understand the decision
[19:09] <_16aR_> maybe they are easier to create
[19:09] <bmhm> I bet Suse and RH did... :)
[19:09] <ScottK-palm> Part of why it's irrelevant.
[19:09] <bmhm> well yeah they ARE easy to create
[19:10] <bmhm> just a signle .SPEC-file (yes, capital letters), and this single file includes all scripts etc.
[19:10] <james_w> jelmer: bzr-webdav and bzr-xmloutput reviewed as well. I'll be happy to advocate any of these packages.
[19:10] <_16aR_> and maybe they are more full-featured ... But from what I've used under red hat, suse, ... I thought it was deep s***
[19:10] <slytherin> _16aR_: isn't the package on revu latest? it's time matches with the output of your command
[19:10] <bmhm> _16aR_: no .deb has more and simpler features
[19:10] <_16aR_> but maybe this is just the tools to exploit rpm that aren't good
[19:11] <persia> slytherin, It's not clear to me.  I argued about it at some length, and finally gave up.  Apparently, they expect other clients to depend on different versions of the platform library, although these don't exist in the archives today.
[19:11] <bmhm> rpm is slow, especially searching
[19:11] <_16aR_> slytherin: \o/ this upload just got it :)
[19:11] <_16aR_> but I've uploaded 4 times this afternoon at least :)
[19:12] <slytherin> persia: these versions are not even parallel installable because they add conflicts/replaces for every old version.
[19:12] <bmhm> ah another question. I created some deb-files with dh_make. Now I want to backport my app to hardy and I get dh_clean: Sorry, but 6 is the highest compatibility level supported by this debhelper.
[19:13] <bmhm> just do sed -i -e 's/7/6' debian/compat ?
[19:13] <persia> slytherin, I know, which makes it completely pointless, but I wasn't able to make my point, and the appropriate parties weren't able to make it to UDS this cycle for a face-to-face chat.
[19:14] <persia> bmhm, Unless you just randomly picked debhelper 7, it's usually more complicated than that.
[19:14] <bmhm> well I'm on intrepid and dh_make put a "7" in there automatically
[19:15] <slytherin> persia: by the way, do you expect me to do any additional check than 'does it build' while sponsoring these packages?
[19:16] <_16aR_> for library, don't I have to create a libnameSONAME package and 1 virtual libname package which depends on the one with the SONAME in it ?
[19:16] <_16aR_> because I get lintian errors on revu
[19:17] <persia> slytherin, I usually build the whole suite, and launch netbeans, but that's about it.  I've been told there's extensive testing of the packages.
[19:17] <slytherin> persia: hmm. Well I am currently building libnb-platform and then will proceed with ide.
[19:18] <persia> slytherin, Feel free to push some of it back to me if you like.
[19:18] <slytherin> why the heck these upstreams use weird version numbers
[19:19] <bmhm> Tex uses 3.1415926.... that's easy!
[19:19] <bmhm> (i think it was tex..)
[19:21] <RainCT> the search box for REVU is ready, will be up in a minute :)
[19:21] <nhandler> Great job RainCT !
[19:22] <bmhm> oh and when I upload packages with dput, I always get:
[19:22] <bmhm> > gpg: WARNING: This key is not certified with a trusted signature!
[19:22] <_16aR_> that's odd. lintian is complaining on my .deb because the packagename doesn't fit with the soname... But for libqt4-network, it doesn't say anything :o
[19:22] <_16aR_> thanks RainCT :)
[19:22] <bmhm> Is this ok?
[19:22] <persia> bmhm, Did you self-sign your key?
[19:22] <_16aR_> bmhm: did you export your key on launchpad/key server ?
[19:22] <bmhm> yes I did
[19:22] <RainCT> it's up, "Search / Filters" at the right top
[19:23] <bmhm> yes I did, too
[19:23] <_16aR_> bmhm: when exactly ? :)
[19:23] <persia> _16aR_, That's not relevant for dput, actually.
[19:23] <bmhm> uhm...
[19:23] <persia> dput only checks the local signature.  It's the repo that checks the keyserver.
[19:23] <bmhm> http://keyserver.ubuntu.com:11371/pks/lookup?op=vindex&search=0x715C2E21FD580CC0
[19:24] <_16aR_> persia: ah ok :)
[19:25] <bmhm> so well, what else could cause the warniing?
[19:25] <bmhm> gpg:          There is no indication that the signature belongs to the owner.
[19:26] <cherva> Is it a problem if I pack a game not with 2 packages game and game-data but in 1 package ?
[19:26] <persia> That usually means there isn't a chain of trust between your keyring and the signing key.
[19:26] <persia> 99% of the time it's because of not self-signing.  I don't understand the other 1%.
[19:27] <bmhm> ah I see =) where would the chain of trust come from?
[19:27] <persia> cherva, Depends on the volume of game data: if there's lots of data that isn't architecture-specific, yes.
[19:27] <bmhm> I didn't sign any ubuntu keys
[19:28] <persia> It's just between you and you, which makes it odd.  It's based on keys signing keys.
[19:28] <bmhm> persia: as long as the packages are being built I could just not care
[19:28] <persia> So if you have, say, three keys, and key1 signs key2, and key2 signs key3, key1 can trust key3, but key3 still doesn't trust key1.  If key3 then signs key1, everyone trusts everyone.
[19:29] <Laney> bmhm: I imagine you need to set the owner trust on your key
[19:29] <persia> bmhm, Until you're uploading somewhere where it matters, not caring is probably easiest.
[19:29] <persia> bmhm, Be warned that you might have issues with certification or encryption of email with a key like that as well.
[19:29] <bmhm> ah Laney that might have been the solution
[19:30] <bmhm> thanks
[19:30] <persia> Laney, Does signing not imply trust?
[19:30] <slytherin> cherva: it depends on the data. If there is a lot of data which is not platform specific then it makes sense to split the package.
[19:31] <bmhm> well persia, I did self-sign my key but trust was set to unkown
[19:31] <Laney> persia: You have to set the level you trust it in addition to signing
[19:31] <cherva> slytherin: OK then someone else will package ultimate stunts because I don't know how to split them..... :)
[19:31]  * persia adds "Read more about key trust metrics" to the list of things to get around to doing
[19:31] <Laney> (AIUI, anyway)
[19:32] <persia> cherva, Well, we'd be happy to help you split them.
[19:32] <Laney> phone verificaition might be partial trust whereas checking ID in person might be full, for example
[19:32] <cherva> persia: :) great
[19:32] <_16aR_> cherva: that's not THAT hard in fact :)
[19:32] <cherva> persia: I suppose I gave to split the data folder
[19:32] <persia> cherva, It's fairly easy, if you use dh_install: just define the two packages in debian/control, and create debian/game.install and debian/game-data.install.
[19:32] <Laney> (I do not know if this is exported to keyservers or just used locally)
[19:33] <persia> The .install files should contain a list of all the files (wildcards allowed) that belong in each package.
[19:33] <cherva> persia: ok let me go to that point ( I'll package it with the help of the video tutorial ) comming in a sec :)
[19:34] <persia> cherva, And as a general note, when you do have your question, just ask it generally: most of us come and go from our terminals, and so you'll often get a response from someone other than the person who last directed you.
[19:35] <cherva> ok 10x
[19:43] <jcfp> when repacking upstream tarball, should that be documented in README.source?
[19:44] <_16aR_> repacking ?
[19:44] <jdong> I'd say what was repacked, why it was done, and how to do it (preferably a debian/rules target but instructions will proably suffice)
[19:45] <jcfp> removing a file, license reasons
[19:45] <jcfp> jdong: I'll automate it via get-orig-source, tx
[19:47] <persia> jcfp, Please also leave a note in README.source indicating that the repack is documented in the get-orig-source rule.
[19:47] <jcfp> k
[19:47] <loic-m> cherva: isn't there a Debian ITP for ultimate stunts?
[19:47] <cherva> ITP ?
[19:48] <loic-m> intention to package
[19:48] <loic-m> in Debian bug tracker.
[19:48] <loic-m> i thought I saw an ITP mention in debian-devel-games or something
[19:50] <loic-m> Bug#515127: ITP: ultimatestunts
[19:50] <cherva> I don't know I just saw https://bugs.launchpad.net/ubuntu/+bug/135852
[19:50] <loic-m> sistpoty filled the ITP
[19:50] <loic-m> you should coordinate with him
[19:51]  * sistpoty has a package already in svn, but both manpages and intense copyright checking are still missing
[19:51] <persia> loic-m, For future reference, if you use the syntax Debian Bug #515127 you get interesting results.
[19:51] <loic-m> persia: thanks
[19:53] <cherva> if I package it today why just I e-mail him and tell him I've allready done it
[19:54] <persia> cherva, I'd suggest starting from SVN, and doing the manpages and intense copyright checking that are needed, rather than starting from scratch.
[19:55] <cherva> doing the manpages?
[19:56] <slytherin> persia: going to bed. Will look at netbeans tomorrow.
[19:56] <persia> Debian Policy mandates that each binary have a manpage.  The person working on the package mentioned above that the manpages needed doing, so that would be a great step towards getting it in.
[19:56] <persia> slytherin, OK.  Let me know if you run out of time, and I'll pick it up.
[19:57] <asomething> persia: I addressed all your comments on sound-theme-freedesktop in REVU: http://revu.ubuntuwire.com/p/sound-theme-freedesktop
[19:58] <james_w> Laney: thanks for your work on the sponsoring queue, it looks much more manageable now
[19:59] <slytherin> persia: sure
[20:00] <persia> asomething, Looks like you did a bit more as well.  If I can find time, I'll take another look tomorrow.
[20:01] <asomething> persia: thanks
[20:03] <RainCT> (added drop boxes to choose archived/unarchived and new/updated to the search box)
[20:06] <Davedan> I'm creating a .deb package which include 2 python files with only few lines of code each. Do I need to put this files under the python2.5 folder?
[20:07] <RainCT> Davedan: is it a standalone application or a module?
[20:07] <persia> Davedan, Are they library files, or just regular scripts?
[20:08] <DktrKranz> iulian, nhandler, sistpoty: about motu-release charter, please have a look and eventually do your adjustments, so we can submit it to MC: https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter
[20:08]  * persia defers to someone who uses the right nomenclature
[20:08] <persia> DktrKranz, Did you mean the other channel?
[20:08] <nhandler> DktrKranz: I'll take a look
[20:08] <persia> Ah, no, meeting change :)
[20:08] <DktrKranz> persia, there is another meeting, so misc stuff is here :)
[20:09]  * DktrKranz is going to do *his* run of "upload to unstable" uploads now
[20:09] <Davedan> RainCT:  persia: just simple scripts that read a file and send http string to a remote web server
[20:10] <Davedan> the scripts are application specific
[20:10] <Davedan>  RainCT: it is a standalone application
[20:11] <RainCT> Davedan: then it isn't necessary, /usr/share/<pkgname>/ is fine. Just be sure to call pycentral/pysupport so that they get byte-compiled
[20:12] <Davedan> RainCT: what about some temp files that are used for processing and then deleted? under /tmp ?
[20:12] <sistpoty> DktrKranz: maybe add s.th. in regards to FinalFreeze (or Milestone Freeze, as it is referred to from FreezeExceptionProcess wiki page)?
[20:12] <RainCT> Davedan: inside the .deb? o.O
[20:12] <Davedan> RainCT: the python script create a temporary file, store some data and few seconds later delete it
[20:14] <RainCT> Davedan: Yes, /tmp is the right place, but be sure to read up how to do it securely (ie, give those files an appropiate owner and permissions et all)
[20:15] <AndrewGee> Hey all. Any MOTUs available to review my package, gpxviewer? It's an application that allows users to look at GPS traces files in GPX format. Thanks :) http://revu.ubuntuwire.com/details.py?package=gpxviewer
[20:15] <DktrKranz> sistpoty, any ideas in particular? I think we should become more strict as time goes, but probably it doesn't need to be mentioned
[20:15] <Davedan>  RainCT: I will read about security. Will I need a make file for just placing 2 scripts under /usr/share/<pkgname>/ and calling pycentral?
[20:15] <RainCT> Davedan: No, dh_install can handle this fine. If you want to create a setup.py file that wouldn't hurt, though
[20:16] <sistpoty> DktrKranz: actually I was referring to the phase were all uploads need to be approved
[20:16] <persia> DktrKranz, I'd change "Powers" to "Responsibilities" because the first three aren't really exercises of power.
[20:16] <Davedan> RainCT: thanks
[20:16] <persia> DktrKranz, Your powers are more likely phrased as "Able to accept or reject any new feature or substantial change ..." (this is just a wording thing).
[20:17] <RainCT> Davedan: you're welcome
[20:17] <directhex> DktrKranz, tracked down the monodevelop problem ^_^
[20:23] <sistpoty> DktrKranz, iulian, nhandler: for netbook (and also mid) ogra suggested StevenK, since he does the images... what do you think?
[20:24] <sistpoty> wow, I guess I highlighted quite a number of people now *g*
[20:24] <iulian> sistpoty: Excellent, I'm fine with it.
[20:25] <DktrKranz> sistpoty, no problems at all
[20:25] <DktrKranz> persia, good point
[20:25] <DktrKranz> directhex, \o/
[20:26] <directhex> DktrKranz, bug in mono.addins
[20:29] <RainCT> james_w: uhm.. the links in the tables look cluttered with an underscore
[20:30] <persia> RainCT, Then don't decorate them that way.  Make them dayglow orange or something.
[20:30] <RainCT> hehe
[20:30]  * sistpoty is off again, need to grab s.th. to eat and then go to bed... cya
[20:34] <aakef> Hello all.
[20:35] <aakef> I need some help with the ubuntu sponsorship concept.
[20:36] <aakef> I'm the package maintainer of a package in Debian. Somebody uploaded this package to ubuntu, but kept me as package maintainer.
[20:36] <directhex> aakef, which package?
[20:37] <aakef> Well, since I also use Ubuntu on my Laptop and since I'm also one of the authors I don't mind.
[20:37] <aakef> directhex: unionfs-fuse
[20:37] <RAOF> Ah.  That's been sync'd unmodified, so it's expected.
[20:38] <directhex> aakef, okay. the version number of the package in ubuntu signifies that it's unmodified - i.e. the exact debian source package has simply been recompiled against ubuntu libc et al
[20:38] <aakef> directhex: I also subscribed to the ubuntu bugreports of that package, I really don't mind to be its maintainer.
[20:38] <RAOF> (The binary package doesn't list you as Maintainer, incidentally)
[20:39] <aakef> directhex: Really? I need to check again then.
[20:39] <directhex> aakef, there are only ubuntu modifiecations in a package if it has "ubuntu" in the version number
[20:39] <RAOF> aakef: Cool!  So, you want to know how to get the fixes you push to Debian into the Ubuntu packages?
[20:39] <aakef> RAOF: Yes exactly.
[20:40] <jcfp> with a repacked tarball, package version should have +repack added, right? so 0.1.2+repack-XubuntuY?
[20:40] <directhex> jcfp, why was it repackaged?
[20:40] <RAOF> aakef: Well, there are two options; you can either file a bug on launchpad, and attach the debdiff against the current Ubuntu package, and subscribe the "ubuntu-universe-sponsors" team to the bug.
[20:40] <jcfp> directhex: license conflict
[20:40] <directhex> jcfp, AFAIK convention (though there's no rule) is +dfsg if you fixed dfsg issues (e.g. removing binary or undistributable components) or +ds ("debian source") for other changes
[20:41] <RAOF> aakef: Or you can push your updates to Debian, and ask for the Debian package to be copied again; requestsync is a tool which will file the appropriate paperwork for you there.
[20:41] <directhex> (requestsync is in ubuntu-dev-tools)
[20:41] <aakef> RAOF: For now it would be fine to have synced the debian changes.
[20:42] <jcfp> directhex: well all components are distributable, but apparently files under Apache license cannot be in the same tarball as a file under GPL (v2 only)
[20:42] <RainCT> Okay, now please suggest a better colour for the links before someone fills a bug: "some links on REVU look awful" :P
[20:42] <aakef> RAOF: Going to run my laptop and see if I can find requestsync there. Don't have a ubuntu chroot presently.
[20:42] <aakef> RAOF: Thanks!
[20:42] <RAOF> jcfp: I find that unlikely; who said that?
[20:42] <RAOF> aakef: No problem!
[20:43] <jcfp> RAOF: ubuntu archive admin (ScottK)
[20:43] <RAOF> jcfp: Certainly, you can't link code under the old Apache license into a GPL'd binary, but simply having the file there?
[20:43] <directhex> jcfp, that could be true. i think gpl3 and apache are compatible
[20:44] <RAOF> jcfp: ScottK knows what he's talking about.  Trust him :)
[20:44] <directhex> "Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in the older version. These include certain patent termination and indemnification provisions."
[20:44] <directhex> apache2 is the wordy version of ms-pl ;)
[20:44] <jcfp> directhex: tell google that
[20:45] <directhex> google, apache2 is incompatible with gpl2, but is fine with gpl3. HTH, HAND
[20:54] <petski> Could one of you MOTU's be so kind to take a look at LP #77980. Bug was created in January 2007. I've created a debdiff which adds a new "feature" to actually resolve the bug. To avoid confusion, it would be nice to include it in jaunty before FeatureFreeze (again, it's a bugfix, not a new feature). Hope somebody can sponsor the upload.
[20:56] <superm1> kirkland, can you try to get the newer mythtv-status pulled in before FF?
[20:56] <kirkland> superm1: sure
[20:56] <kirkland> superm1: i have a note in my inbox from the author
[20:56] <kirkland> superm1: as you can imagine, it's been crazy
[20:56] <superm1> kirkland, thanks
[20:56] <superm1> of course :)
[20:57] <superm1> thankfully it's probably an easy merge generally, or if we're lucky sync :)
[20:58] <chrismurf> mok0, just saw pyproj made it into the jaunty queue -- thanks again for all the help :-)
[20:58] <lfaraone> Hi, I added a .patch file to the debian/patches folder for a package, dch -i'd, and debuilt the source. Why is it then that debdiff says there were no changes made to the dscs other than the changelog addition? (afaict it uses simple-patchsyss)
[20:59] <riot_le> hi, i'am new to packaging and need help with REVU, the x2go-Project builds Packages for Jaunty, Problem is that the Main-Dev hasn't so much time at the moment and so i should help to bringing x2go in Ubuntu. Maybe one here who can give me a helping hand? For infos about x2go take a look here: http://x2go.obviously-nice.de/index.php?id=48
[21:00] <riot_le>  nick barcet wrote me that the Feature Freeze is at 19.February so time is small to manage
[21:03] <riot_le> the ubuntu repo of x2go is here: http://x2go.obviously-nice.de/deb/pool-ubuntu/
[21:03] <riot_le> deb http://x2go.obviously-nice.de/deb/ ubuntu main
[21:05] <petski> hi lfaraone, which package are you trying to change?
[21:08] <riot_le> no one out who can help?
[21:09] <mok0> riot_le: you can't make it for jaunty
[21:09] <riot_le> mok0: why?
[21:10] <mok0> riot_le: because it takes time to get a package reviewed, and everybody is busy wrapping up their stuff
[21:11] <riot_le> mok0: thats really bad news, cause the Devs takes much time to customize their Packages to Ubuntu
[21:11] <mok0> riot_le: there are > 100 packages in the queue, many have not been reviewed at all
[21:12] <mok0> ! revu > riot_le
[21:12] <mok0> riot_le: you can release the package from a PPA
[21:13] <c_korn> ! revu > c_korn
[21:13] <mok0> riot_le: and then work to get it into the next release 9.10
[21:13] <_16aR_> hi REVU people ! I got one 2D physics game engine to be reviewed : http://revu.ubuntuwire.com/p/box2d , thank you :)
[21:14] <lfaraone> petski: a package in main, gnome-mount.
[21:15] <fransman> Looking for a debian ticket related to bug 330150.
[21:15] <fransman> Want to add it.
[21:15] <lfaraone> fransman: Ok, then use Google or the Debian BTS.
[21:15] <lfaraone> fransman: http://bugs.debian.org/ :)
[21:15] <riot_le> mmh, thats the same Problem like in 8.10, the repo isn't the Problem, they Provided an own one, but there are some Organisations who want to use x2go in combination with Ubuntu but only can use official Ubuntu Sources
[21:15] <james_w> lfaraone: hey, got a minute for sugar?
[21:15] <lfaraone> james_w: Sure, fire away.
[21:16] <lfaraone> james_w: (I just got back from a church retreat)
[21:16] <fransman> lfaraone: I did before asking
[21:16] <james_w> lfaraone: terminal and turtleart don't build for me
[21:16] <james_w> lfaraone: terminal looks for "Terminal.activity" which is mentioned in the .install file, and it isn't present.
[21:16] <lfaraone> fransman: Ok, then please ask the Debian people, although they will no doubt have no more ide than we do.
[21:16] <james_w> lfaraone: are these typically built, or shipped in the source package?
[21:16] <lfaraone> james_w: Hm, I'll look into that.
[21:17] <fransman> lfaraone: will do
[21:17] <james_w> lfaraone: please do, I'll sponsor the updates if you can work it out
[21:17] <lfaraone> james_w: Shipped in the source.
[21:18] <lfaraone> james_w: unzipping the .xo or .tgz results in the source code inside a NAME.activity folder by convention.
[21:18] <james_w> the new tarballs ship an "activity/activity.info" file, could that be it?
[21:18] <james_w> [Activity]
[21:18] <james_w> name = Terminal
[21:18] <james_w> etc.
[21:18] <lfaraone> james_w: I'll look.
[21:20] <james_w> thanks RainCT
[21:21] <Davedan>  is there a simple way to package an application that has 2 simple python scripts + 1 config file + 1 file that is plaeced in /etc/apt/apt.conf.d/ ?
[21:21] <Davedan> the application will be downloaded from my website so I don't need it to be 'official'
[21:21] <RAOF> Davedan: Absolutely; check out 'man dh_install'
[21:22] <Davedan> RAOF: ok
[21:23] <lfaraone> james_w: hm, what's an .install  file?
[21:23] <james_w> lfaraone: debian/install
[21:23] <james_w> or debian/<pkgname>.install
[21:23] <lfaraone> james_w: ah...
[21:28] <RainCT> quadrispro: you know that you should redirect the e-mail you get after uploading a package from REVU to ubuntu-motu@?
[21:29] <quadrispro> RainCT: eh, I didn't know, I'm doing it now
[21:29] <quadrispro> sorry
[21:30] <RainCT> quadrispro: No problem. (There's also some stuff on https://wiki.ubuntu.com/MOTU/New which you should have a look at if you don't know it already -although you probably do by now :)-)
[21:31] <quadrispro> thank you RainCT
[21:40] <jcfp> Any motu around to take a look at http://revu.ubuntuwire.com/p/sabnzbdplus - package was rejected by the archive admins due to a license conflict (Apache + GPL-2; issue fixed by repack).
[21:40] <Davedan> how do I prompt a user for input such as a password when he installs my package?
[21:40] <Laney> Davedan: look into debconf
[21:41] <Davedan> Laney: thanks
[21:42] <ScottK> jcfp: How'd you deal with the GPL2 only file?
[21:42] <jcfp> ScottK: deleted it
[21:42] <ScottK> OK.
[21:42] <ScottK> jcfp: How about cherrypy?
[21:43] <jcfp> ScottK: it's not used in the binary package at all
[21:43] <jcfp> never was too
[21:43] <ScottK> jcastro: OK.  That wasn't clear.
[21:43]  * ScottK will look.
[21:44] <_16aR_> hi REVU people ! I got one 2D physics game engine to be reviewed : http://revu.ubuntuwire.com/p/box2d , thank you :)
[21:44] <_16aR_> oops sorry
[21:45] <ScottK> Sorry jcastro.  Tab completion failure.
[21:45] <jcastro> no worries
[21:45] <RainCT> go, quadrispro, go :)
[21:45] <ScottK> jcfp: We certainly looked for the lgpl copy ...
[21:45] <directhex> jcastro, *cough*
[21:47] <Laney> Someone who knows about licenses (hello archive admins!) should write a page on "how to review licenses for MOTUs"
[21:47] <Laney> does such a page exist already?
[21:47] <quadrispro> RainCT: :D
[21:47] <ajmitch> ScottK: I'm sure jcastro doesn't mind being pinged on irc too much :)
[21:47] <directhex> ajmitch, i'm sure he doesn't mind me pinging, especially. i'm great!
[21:48] <ScottK> We can probably come up with a script.
[21:48] <RainCT> quadrispro: what's next on your list? (so that I don't review the same)
[21:49] <Laney> ScottK: How does a non Canonical employee (unless I'm mistaken) become an archive admin anyway? I thought this was a blessed role
[21:49] <koke> hi all, I have a patch for mlmmj, should I send it to debian directly or go to launchpad first?
[21:49] <koke> http://people.warp.es/~koke/patches/mlmmj-dash.debdiff
[21:49]  * quadrispro @ phone
[21:49] <RainCT> Laney: Launchpad has an interface for some archive admin stuff, and there are a few community members beta testing it
[21:49] <ScottK> Laney: There's stuff you need ssh access for that I can't do.  I'm limited to what the LP UI can do
[21:50] <ajmitch> koke: hey, long time no see :)
[21:50] <koke> yep :)
[21:50] <_16aR_> what for a library the pkg-config is mandatory ? or only better to have ?
[21:50] <ajmitch> koke: looking at the list of debian uploads for it, the maintainer hasn't been so active
[21:50] <koke> I have forgotten a lot of things :)
[21:50] <ajmitch> so it may take awhile for the patch to lanf
[21:51] <ajmitch> s/lanf/land/
[21:51] <koke> I guess the problem exists only in ubuntu
[21:51] <ajmitch> quite likely
[21:51] <koke> because it's using dash
[21:51] <ajmitch> last debian upload fixed bashisms
[21:51] <ajmitch> http://packages.qa.debian.org/m/mlmmj/news/20080308T224708Z.html
[21:52] <ajmitch> koke: which ubuntu version are you grabbing that package from?
[21:52] <koke> intrepid
[21:52] <ajmitch> hm
[21:52] <ajmitch> because I see 1.2.15-1.1 in intrepid
[21:53] <koke> same version since gutsy
[21:53] <ajmitch>      mlmmj | 1.2.15-1.1 | http://archive.ubuntu.com intrepid/universe Packages
[21:54] <cpscotti> Hello, what is the best source/how-to on making a "home-made" software into meeting Ubuntu packaging needs? Is it https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages ???
[21:54] <Laney> aha
[21:56] <sven777> would a MOTU be so kind as to review my package?  (It already has one advocate.) Thanks in advance!  http://revu.ubuntuwire.com/p/lmalinux
[21:56] <ajmitch> cpscotti: the packging guide linked at the top of that page would be most helpful, I think
[21:56] <nhandler> sven777: You lose the advocation when you prepare a new upload
[21:57] <sven777> nhandler - doh I didn't realize that
[21:57] <sven777> well, it *was* advocated :)
[21:57] <ajmitch> koke: so... not sure how you're seeing the older package
[21:57] <nhandler> :)
[21:57] <mok0> sven777:  no I'm still advocating
[21:58] <cpscotti> ajmitch: thanx... I see there's a big bureaucracy.... (I see it is indeed necessary... but)
[21:58] <sven777> mok0: oh ok great :)
[21:58] <koke> opps, sorry
[21:58] <koke> ajmitch: hardy :)
[21:58] <james_w> http://kitenet.net/~joey/blog/entry/debhelper_dh_overrides/
[21:59] <koke> I thought I was logged to another machine
[21:59] <ajmitch> heh
[21:59] <ScottK> jcfp: Looks good.  Uploaded it.  Thank you for your contribution to Ubuntu.
[21:59] <koke> it looks like it should install cleanly on hardy
[22:00] <_16aR_> don't review box2d right now, I'm uploading a new version ... (which compiles hello world ... that's better ...)
[22:00] <ajmitch> it'd be nice if it did
[22:01] <ajmitch> koke: how have you been, anyway?
[22:01] <koke> fine :)
[22:01] <koke> I'll be working at ebox now
[22:02] <ajmitch> going to be working more with ubuntu?
[22:02] <koke> after two years as mysql instructor
[22:02] <koke> so open source was a good bet :)
[22:02] <jcfp> ScottK: tx, my pleasure (most of the time ;)
[22:02] <koke> probably
[22:02] <directhex> how often does debian incoming migrate to debian's archive (for requestsyncing)
[22:03] <pochu> directhex: 4 times a day
[22:03] <Laney> http://incoming.debian.org says when the dinstall runs are
[22:03] <koke> although I'm not an official developer, more like the IT guy
[22:03] <directhex> blarg, 2am
[22:03] <ajmitch> koke: still good to be doing something different
[22:03] <koke> yep
[22:03] <ajmitch> pochu: I think it's twice a day right now
[22:04] <koke> I'm trying to use ebox as much as possible for our internal systems
[22:04] <koke> and that includes mailing lists
[22:04] <persia> cpscotti, You may also find https://wiki.ubuntu.com/UpstreamGuide useful in preparing the software for packaging.
[22:04] <koke> and I'm trying to create a module with mlmmj
[22:04] <pochu> ajmitch: did they revert the change?
[22:05] <ajmitch> pochu: ah no, it's just testing migration that's just happening twice a day at the moment
[22:05] <_16aR_> ok, box2d new upload is there
[22:05] <ajmitch> due to lenny release
[22:06] <AdamDH> whats the correct way to write a copyright file as there seems to be a couple of ways, one here https://wiki.ubuntu.com/PackagingGuide/PackagingOverview and looking at the new binutils-2.19-1 package the file looks diffrent
[22:07] <persia> AdamDH, There are two recommended formats for debian/copyright.
[22:07] <AdamDH> should I go with the one in the ubuntu wiki?
[22:07] <persia> http://wiki.debian.org/Proposals/CopyrightFormat and http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
[22:08] <persia> Pick the one that makes more sense to you.  If you don't care, picking the first of the two I suggested helps establish practice.
[22:10] <AdamDH> i will porbally go with the first one as it makes more sense to the package I am working on
[22:11] <AdamDH> if the package I am working on is applying a patch to an upstream GNU binutils source half of that belongs to the upstream so applys to that license, do I then note the files under the second license for the modifications from the patch?
[22:15] <_16aR_> as said before, I want to package a game. And that game depends on the box2d library package I just "finished" (until new comments ;)). I've heard there some apt-get revu directory, right ? so I can add it to pbuilder
[22:16] <maxb> I'm fairly sure revu is not apt-gettable
[22:17] <maxb> It would not make sense, given that you are allowed to replace versions in revu
[22:17] <persia> maxb, There was a patch floating around for a while that did that.
[22:17] <persia> No, it's *not* reliable, and it was source-only, but it existed.
[22:17] <maxb> oh, I guess source-only is less of a problem
[22:19] <persia> REVU doesn't do builds.  There was a patch for that too, but it was rejected, as there are too many ways to hang a build, and there just aren't enough resources (plus there are PPAs).
[22:21] <_16aR_> ok
[22:21] <_16aR_> I don't why I thought it has one :o I thought I read it last week :o
[22:23] <nhandler> persia: I thought the REVU source repository was still active
[22:23] <persia> nhandler, Is it?  I thought it got dropped in some recent rev.  I haven't looked in a while, as I usually dget.
[22:23] <nhandler> https://edge.launchpad.net/revu/+announcement/1224
[22:23] <nhandler> I don't know. I haven't heard anything about it being dropped, but I don't use it either
[22:25] <persia> I wonder if it got updated for jaunty.
[22:28] <maxb> I'm confused by the sort order of packages in REVU - it looks *mostly* sorted by upload date, but there are some oddities
[22:29] <cpscotti> persia: thanks... the more things to read.. the better =]
[22:29] <nhandler> maxb: If a package gets a non-advocating comment by a MOTU, it goes to the Needs Work list. When they upload a new version, it goes to the end of the Needs Review list
[22:29] <_16aR_> nhandler: HTTP 403 :)
[22:29] <maxb> yes... but what about the sort order within the "Needs work" list?
[22:30] <nhandler> maxb: I'm not sure how that is sorted. If I had to guess, it is sorted by the date it got sent to the list, but I'm not positive
[22:30] <nhandler> maxb: It doesn't really matter, most MOTUs ignore that list
[22:31] <persia> maxb, The more times it gets rejected, the more it gets pushed down.
[22:31] <maxb> ah, *that's* why it's in semi-date order
[22:31] <persia> Once a MOTU rejects, all non-MOTU/non-uploader comments automatically count as rejections.
[22:32] <persia> It's just an accident of the SQL query that never got fixed because none of the reviewers look at that list unless they want to adopt an abandoned package.
[22:34] <nhandler> I didn't even know about that persia. Thanks ;)
[22:35] <persia> nhandler, Happy to share.  That one is probably my fault, because I reviewed the SQL statement when it was written, and it's big and scary enough that RainCT has been avoiding it.
[22:36] <RainCT> hehe
[22:36]  * RainCT didn't know this either :P
[22:36] <_16aR_> lol
[22:37] <RainCT> guess I should have a look at the query.. :P
[22:37] <ajmitch> probably because SQL is full of hidden evils
[22:37] <persia> It's not exactly intentional behaviour, and I think the requirements for the SQL query were about 2K in length.
[22:37] <_16aR_> ajmitch: SQL is always full of hidden evils
[22:37] <RainCT> once I add neutral comments, I guess
[22:39] <persia> RainCT, See, I'm still unsure about this neutral comments thing, in part because it means changing that query :)
[22:44] <RainCT> persia: don't worry, that query can't get more complicated than it is now :)
[22:44] <persia> RainCT, Sometime you and I should sit down so I can explain just how complicated a fourth generation language can be.  There's a reason we don't tend to write applications that way.
[22:45] <RainCT> persia: 4th generation language?
[22:46] <persia> http://en.wikipedia.org/wiki/4GL
[22:47] <RainCT> persia: OK, I see. But I still fail to understand what you mean with that sentence :(
[22:47] <_16aR_> hmmmm anyone has a method to avoid problems with ppa when you upload the exact same ubuntu version ?
[22:47] <Laney> use different (lower) version numbers for PPAs
[22:47] <persia> Well, SQL is a 4GL...
[22:48] <RainCT> yep
[22:48] <_16aR_> I don't want to pollute my changelog with new version since my main goal is the REVU
[22:48] <_16aR_> Laney: what do you mean ?
[22:48] <nhandler> _16aR_: Append ~ppaX to the version
[22:48] <RainCT> persia: but - «There's a reason we don't tend to write applications that way.» what way is that?
[22:48] <_16aR_> ok
[22:48] <persia> RainCT, In 4GL (or higher) environments.
[22:48] <_16aR_> nhandler:  but I still need to modify change log, right ?
[22:48] <persia> We tend to write mostly 2GL or 3GL code.
[22:49] <nhandler> _16aR_: Yes, but then just revert those changes before uploading a new version to REVU
[22:49] <_16aR_> ok
[22:49] <_16aR_> still bugging ^^
[22:49] <_16aR_> but thanks :)
[22:50] <nhandler> You're welcome _16aR_
[22:50] <RainCT> persia: OK, so basically your comment was that you don't like SQL? :P
[22:51] <_16aR_> since I deleted my old package, how can we undelete from ppa ? because it is still on the list :(
[22:51] <_16aR_> or may a new upload undelete it ?
[22:51] <persia> Actually, I once wrote an entire online banking system in PL/SQL, including rebuilding most of the broken webserver I was provided.  My claim is that it's *complicated* and has the potential to be *extremely* complicated, in ways that earlier generation languages can only imagine.
[22:51] <RainCT> wow
[22:52]  * RainCT wonders: Why would you do such a thing? o_O
[22:52] <ajmitch> persia: that just sounds masochistic
[22:52] <DktrKranz> RAOF, could you please have a look at evolution-sharp and eventually manage GNOME# transition before FF? I noticed you are in contact with upstream to fix some API changes.
[22:52] <_16aR_> persia: when you speak of : "We tend to write mostly 2GL or 3GL code.", you speak for whom ?
[22:52] <RAOF> DktrKranz: Has the new point release come out yet?
[22:53] <persia> ajmitch, No, masochism is writing a data entry toolkit in SPSS/X.  PL/SQL isn't so bad.
[22:53] <persia> _16aR_, Most programmers active in this channel.  Most programmers who have contributed code to Ubuntu.
[22:53] <RAOF> DktrKranz: Because, while I know it's broken now, I'm not uploading a package that breaks API only to have it changed back almost immediately :)
[22:53] <DktrKranz> RAOF, not yet, they only have 0.19.
[22:53] <DktrKranz> *0.19.2
[22:54] <_16aR_> persia: except when some enlightened guy thinks he is object programming by creating a new package for every function he creates. At the end, 200 PL/SQL package to manage for nothing, thanks :p
[22:54] <Laney> Don't suppose anyone knows of an exmple watch file that matches GNOME-style (odd/even) stable releases only?
[22:55] <persia> _16aR_, That's not how you're supposed to do it, but it is an example of the complexity.
[23:00] <pochu> Laney: any gnome watch file ;)
[23:00] <_16aR_> anyone knows how to "undelete" package from ppa K?
[23:00] <Laney> pochu: Heh ¬_¬ I didn't think they usually did that
[23:00]  * Laney spies one
[23:00] <binarymutant> with requestsync what is <target release>? would it be "9.04" or "Jaunty"?
[23:00] <pochu> Laney: e.g. http://download.gnome.org/sources/totem/([\d\.]+)[02468]/totem-([\d\.]+)\.tar\.gz
[23:00] <nhandler> binarymutant: jaunty
[23:00] <binarymutant> thank nhandler
[23:00] <RainCT> well, good night all :)
[23:01] <Laney> pochu: Aha! I was close
[23:01] <_16aR_> good night RainCT
[23:01] <persia> _16aR_, Ask in #launchpad
[23:01] <_16aR_> persia: hmmm ^^ good point lol
[23:02] <binarymutant> if I use the -lp option with requestsync will I be subscribed to the bug?
[23:02] <binarymutant> --lp*
[23:03] <nhandler> binarymutant: You are automatically subscribed to all bugs you report on LP
[23:03] <binarymutant> cool
[23:04] <james_w> could a spanish speaker translate the error messages in http://launchpadlibrarian.net/22706083/DpkgTerminalLog.txt please?
[23:05] <persia> james_w, I don't speak spanish, but it looks like a broken download (the archive is damaged)
[23:06] <nhandler> Here is what Google translates it as "dpkg: error processing / var/cache/apt/archives/consolekit_0.2.10-1ubuntu10_i386.deb (- unpack):    filesystem tar file corrupted - corrupted package archive  "
[23:06] <persia> corrupted is probably more correct than damaged: computers are better than inerudite humans.
[23:09] <binarymutant> can I request sync from Debian's "NEW" queue or do I have to wait?
[23:09] <ScottK> Debian's New queue is not publically accessible.
[23:10] <binarymutant> so wait :/
[23:10] <_16aR_> Hmmm, I got 1 more question, what env var/conf file does dch use to complete the "new version" template (dch -i ) ?
[23:11] <pochu> _16aR_: it depends on DEBCHANGE_RELEASE_HEURISTIC
[23:11] <pochu> err, no
[23:11] <_16aR_> sorry pochu, I was speaking for the fullname and email
[23:11] <_16aR_> it seems debfullname and DEBEMAIL doesn't work
[23:11] <_16aR_> for that
[23:11] <pochu> _16aR_: oh, that comes from DEBEMAIL and DEBFULLNAME
[23:11] <_16aR_> ok
[23:11] <_16aR_> I'll try agaiin then
[23:12] <_16aR_> pochu: no, it doesn't work :(
[23:12] <pochu> _16aR_: you sure? it should
[23:13] <_16aR_> for now, it is using the system fullnam and mail is composed from login@hostname
[23:13] <_16aR_> on the localmachine
[23:13] <pochu> _16aR_: try:
[23:13] <pochu> export DEBEMAIL=foo@gmail.com
[23:13] <pochu> dch -i
[23:13] <nhandler> _16aR_: Where did you set those variables?
[23:13] <pochu> and see
[23:14] <_16aR_> nhandler: in my term juste before launching dch -i
[23:14] <nhandler> _16aR_: How did you set them? In your .bashrc?
[23:14] <_16aR_> haha ... I needed to export them !
[23:14] <_16aR_> thanks pochu
[23:14] <_16aR_> and nhandler
[23:17] <_16aR_> that's so bad revu doesn't increase karma, I'm fond of ladders !
[23:17] <_16aR_> ................
[23:17] <_16aR_> ^^
[23:18] <_16aR_> By the way, the fact that revu is not under ubuntu.com is a mean to make understand it is the community and not affiliated with canonical ?
[23:18] <_16aR_> or another choice ?
[23:18] <ScottK> That's it.
[23:18] <persia> It's part of infrastructure provided by the Ubuntuwire project.
[23:19] <nhandler> _16aR_: REVU is not a requirement for getting new packages into Ubuntu. You just need to get 2 MOTUs to advocate it
[23:19] <_16aR_> nhandler: ok
[23:19] <Laney> 2 MOTUs isn't even a policy requirement, is it?
[23:19] <_16aR_> anyway, revu is a GREAT tool, and thanks everybody involved in it :)
[23:19] <nhandler> Laney: I thought it was
[23:19] <ScottK> Laney: For packages from non MOTU it is.
[23:19] <persia> Laney, No, it's considered good practice to have peer review.
[23:19] <Laney> oh, where is that written down?
[23:20] <persia> 2 MOTUs does it, or a DD (willing to upload to Debian) and a MOTU, or many other combinations.
[23:20]  * ScottK hands Laney wiki.ubuntu.com and a search enging.
[23:20] <Laney> persia: Right, I understand the difference between practice and policy
[23:20] <ScottK> engine evern.
[23:20] <persia> ScottK, There are counterexamples: I'm not sure it's policy, just ironclad practice.
[23:20] <_16aR_> ScottK : even ? :p
[23:21] <ScottK> _16aR_: Yes
[23:21] <nhandler> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Alternative%20workflows
[23:21] <james_w> it still seems pretty silly to me
[23:21] <ScottK> persia: We had a documented requirement at one point.
[23:21] <persia> ScottK, I remember that.  I thought we got shot down.
[23:21] <persia> We could raise it again.
[23:22] <ScottK> persia: I thought we got shot down about extending the two MOTU requirement to MOTU.
[23:22] <ScottK> persia: That's also what the page nhandler linked says.
[23:22] <persia> I'd have to review things in lots more detail than I can remember.  One of us is right, and in either case, it's unlikely that many packages will be uploaded without two developer review.
[23:23] <persia> Ah, good then.  I'm glad to be wrong.
[23:23] <ScottK> Even for MOTU getting a review is encouraged, but not required.
[23:24] <nhandler> "MOTUs can upload new packages directly to the archive. However they are greatly encouraged to have a new package reviewed prior to uploading"
[23:24] <Laney> Why would a MOTU be able to upload a package without external review, but not be trusted to review and upload a contributor's package solely?
[23:24] <Laney> s/solely/alone/
[23:25] <persia> Laney, Because we make mistakes.
[23:25] <Laney> persia: Right. Which means that we should be required to seek feedback on our own packages.
[23:25] <persia> Consider the alternate question: why should MOTU be able to upload a new package when they aren't trusted to review and upload a contributer's package solely?
[23:25] <Laney> exactly
[23:25] <james_w> yes, but if we can exercise judgement in requesting review of our own packages, why can't we exercise judgement in getting a second review of someone else's?
[23:26] <persia> Laney, Please raise it on the mailing list, and schedule a MOTU meeting (traditionally on Fridays) for discussion.
[23:26] <Laney> I was disputing the asymmetry, not which way round it should be resolved
[23:26] <ScottK> Laney: I don't defend the current practice as entirely rational, but it's a reasonable compromise.
[23:27] <persia> james_w, That too.  The current policy is asymmetric, and probably needs work.  I'm very much in favour of review, given the many package advocations and MOTU packages I've rejected, but it's been long enough to warrant more discussion.
[23:28] <Laney> persia: I am happy to raise it, but I do not have the energy to go over the arguments in detail
[23:29] <james_w> I would favour strongly encouraging motu's to request a second advocate for new packages from other contributors. It may let in a couple of mistakes when they don't (and some when they do of course), but it would at least make the policy consistent
[23:29] <persia> james_w, So reducing the requirements for new packages?
[23:29] <james_w> making it a SHOULD rather than a MUST I guess
[23:30] <james_w> with probably little practical change
[23:30] <persia> And perhaps adjusting the other also to SHOULD rather than MAY?
[23:30] <james_w> yeah
[23:31] <james_w> and I don't think new packages should be particularly special, we should encourage requesting reviews from other motus on any change where we feel more review is needed
[23:31] <persia> We'd probably benefit from a richer review system for that.
[23:32] <james_w> luckily we have one, if only someone would make it possible to use it for all packages :-p
[23:32] <persia> When existing packages weren't expressly hidden on REVU, they caused several collisions.
[23:50] <surfaz> Any Motu?
[23:50] <surfaz> https://bugs.launchpad.net/ubuntu/+source/blender/+bug/320045
[23:50] <surfaz> https://bugs.launchpad.net/ubuntu/+source/avidemux/+bug/328492
[23:51] <nixternal> ok my regex ninjas... creating an svn hook... Only want US|DE with 4 digits following... [US|DE]\d{4} doesn't work for me... ((US|DE)[0-9]{4} allows me nothing less than the 4 digits, but allows 5+ digits as well
[23:52] <AdamDH> any one know any packages using this copyright system http://wiki.debian.org/Proposals/CopyrightFormat?
[23:53] <RAOF> AdamDH: Yup.  Many of the pkg-cli-apps packages use that; gnome-do is one.
[23:54] <andersk> nixternal: what flavor of regexes?
[23:54] <nixternal> shellzors
[23:55] <_16aR_> AdamDH: I maybe not an example, but the hexdiff package use it :p
[23:55] <_16aR_> AdamDH: http://launchpadlibrarian.net/22623176/hexdiff_0.0.53-0ubuntu1.dsc
[23:55] <andersk> You basically want to add the condition that the next character is not a digit.  So (US|DE)[0-9]{4}[^0-9] or (US|DE)[0-9]{4}$
[23:56] <AdamDH> thanks RAOF _16aR_ I was just looking to see of my package copyright is written correctly
[23:57] <AdamDH> whats the best line length to use in the copyright file? I am working on a cross compiler based on binutils so for Copyright: 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc. seems a tad to long
[23:57] <AdamDH> can I just do 1990 - 2007?
[23:58] <nhandler> I think for that many, 1990-2007 should be fine
[23:58] <persia> nixternal, Consider ((US|DE)[0-9]{4}[^0-9])
[23:58] <AdamDH> actually it should be 2009
[23:58] <AdamDH> I pasted that from 2.19 for januity
[23:58] <persia> (this presumes there exists some extra character that isn't a digit)
[23:58] <nhandler> AdamDH: As for line length, it should be under 80 characters
[23:58] <AdamDH> thanks nhandler
[23:58] <persia> Alternately ...[0-9]{4}$) to match end of line.
[23:59] <nhandler> You're welcome AdamDH
[23:59] <directhex> persia, are you java team? i forget
[23:59] <persia> directhex, Let me ask why before I confirm or deny :)
[23:59] <_16aR_> I'm leaving :)
[23:59] <_16aR_> but before :) One last spam :)
[23:59] <persia> (as in, only if it doesn't involve ikvm)
[23:59] <nixternal> persia: didn't work