[00:00] <handschuh> mok0: why cant you test it? test if it builds?
[00:00] <Hobbsee> RAOF_298: use ppa for it, instead?
[00:00] <ajmitch> hello Hobbsee
[00:00] <mok0> handschuh: It builds fine, but not being a java programmer, I can't verify that the library works as advertised
[00:01] <Hobbsee> hey ajmitch!
[00:01] <handschuh> mok0: a ok, thats fine
[00:01] <RAOF> Hobbsee: That seems somewhat against the spirit of the PPA, though
[00:01] <RAOF> ?
[00:01] <handschuh> mok0: thanks for reviewing
[00:01] <Hobbsee> RAOF: well....
[00:02] <Hobbsee> RAOF: it's for testing packages, and distributing them if they're good?
[00:02] <RAOF> As opposed to just testing whether they build or not? :)
[00:02] <RAOF> I could, I suppose.  Jaunty's now PPAable, isn't it.
[00:03] <Hobbsee> well, if they don't build, then they don't get distributed.  if they do build, people get them via the ubuntu repos anyway, so the ppa versions will be overwritten
[00:03] <Hobbsee> yes, i believe so
[00:08] <binarymutant> in a man page, does = need to be \= ?
[00:18] <mok0> binarymutant: you mean escape the minus? No
[00:18] <mok0> s/minus/equal
[00:19] <binarymutant> thanks mok0
[00:29] <joaopinto> erm
[00:29] <joaopinto> http://revu.ubuntuwire.com/details.py?upid=2998 <- dpatch is on the build depends, how could it fail to build ?
[00:32] <RAOF> Why are you including both /usr/share/dpatch/dpatch.make and /usr/share/cdbs/1/rules/dpatch.make?
[00:34] <joaopinto> good question, copy&paste
[00:35] <joaopinto> well, at least the package got a review :P
[00:37] <joaopinto> I will fix the dpatch double inclusion once I get more things to fix
[01:00] <ryanakca> Can mk-sbuild-lv be used to create Debian schroots?
[01:02] <RAOF> That's how I built my sid chroot, yes.
[01:03] <RAOF> I may have had to specify a different mirror or something; it's been a while, and the disc that has those schroots is sitting in a box with (at least) a blown power supply.
[01:05]  * RAOF wonders whether it'd be considered polite to test the grub2 installs and works before uploading :)
[01:06] <Hobbsee> RAOF: uh, yes.
[01:06] <StevenK> It's a bootloader. You should try it yourself and in a virtual machine
[01:08] <ajmitch> RAOF: just put a link to your package on the forums
[01:08] <RAOF> Juuust kiddin.
[01:09] <RAOF> ajmitch: Good plan!
[01:09] <RAOF> Cmon LP.  Publish those binaries.
[01:09] <StevenK> But rename it to openoffice.org3
[01:09] <ajmitch> you'll soon hear of any probelms
[01:10] <ScottK> Be sure and set the maintainer to ajmitch before you put it in your PPA though.
[01:10]  * StevenK grins
[01:10]  * ajmitch sets up procmail to bounce any mail about grub2 to ScottK 
[01:13] <ryanakca> RAOF: thanks
[01:15] <zul> ajmitch: evil
[01:23] <emgent> hello people
[01:25] <nhandler> mHey emgent
[01:26] <emgent> heya master
[01:26] <emgent> :)
[01:26] <nhandler> emgent: I still need one more +1 before you can call me that ;)
[01:27] <emgent> hahah
[02:39] <effie_jayx> hey all , what is the command for knowing what patch sys the packages uses
[02:39] <effie_jayx> =
[02:40] <tbielawa> I recommend checking what the build depends are
[02:41] <jdong> a quick look at debian/rules's includes is often indicative, too
[02:41] <tbielawa> yep
[02:41]  * ajmitch dies a little inside seeing questions about checkinstall
[02:42] <RAOF> There's also the "what-patch" script shipped in... devtools?
[02:42] <persia> ubuntu-dev-tools
[02:42] <RAOF> persiabot is faster than dpkg -S :)
[02:43] <jdong> ajmitch: you mean... that's not how you make a deb?
[02:43] <jdong> ajmitch: do you recall someone coming into #ubuntu-devel a year ago trying to build a deb by using dh_make && dpkg-buildpackage in one fell swoop?
[02:43] <ajmitch> jdong: no, you use ar
[02:44]  * jdong sees Firefox 3.0.4 crack in jaunty and pre-backports
[02:45] <tbielawa> lol
[02:50] <binarymutant> anyone know of any good tutorials on dpatch? besides the wiki and morph's blog?
[02:52] <persia> binarymutant, Generally it's just datch-edit-patch patchname, and including the right dpatch makefile fragment.
[02:52] <RAOF> binarymutant: What aspect of dpatch would you like a tutorial for?  I find it pretty self-explanitory.
[02:53] <RAOF> zsh (at least) will even tab-autocomplete the patchname for you, if you're editing an existing patch.
[02:58] <effie_jayx> ok... I have been goolgling about doing the import for quilt in debian/rules ... can anyones direct me as where to read about this?
[03:00] <binarymutant> well do I create 00list for dpatch?
[03:00] <RAOF> binarymutant: 'emacs debian/patches/00list'
[03:01] <binarymutant> RAOF, so ya, because that would be a new file for me
[03:02] <jdong> RAOF: you mean vi?
[03:02] <RAOF> jdong: No, because I'm a worshiper of the One True Operating System.
[03:03] <coppro> emacs?
[03:03] <RAOF> Right.
[03:03]  * coppro uses neither!
[03:04] <effie_jayx> found it :D
[03:12] <effie_jayx> I am using a patch system and I am sure I did not touch the code, yet lintian complains about "patch-system-but-direct-changes-in-diff .pc/.version" any clues?
[03:15] <RAOF> I suspect that's a quilt-related directory, but I'm not sure.
[03:15] <RAOF> "Fetched 15.6MB in 1h59min35s (2169B/s)".  Yay.
[03:15] <effie_jayx> how could I check this?
[03:16] <coppro> LOL
[03:16] <ajmitch> RAOF: welcome to the first world
[03:16] <RAOF> Well, you could see what's in that directory.  But man quilt contains a reference to .pc.
[03:16] <jdong> I remember those days.
[03:17] <ajmitch> jdong: and people in the US dare to complain about a 250GB limit
[03:18] <jdong> ajmitch: well that's more because you are paying $80/mo for "unlimited" internet
[03:18] <RAOF> jdong: Really USD$80/mo?
[03:19] <jdong> RAOF: some of the Comcast plans are around that price, yes.
[03:19] <RAOF> I hope you get crazygood bandwidth, then.
[03:19] <jdong> RAOF: I know my neighbors on Comcast pay about $120 for high-speed internet and cable TV combined
[03:19] <jdong> yeah he's got some crazy 10 or 12mbit plan
[03:19] <jdong> which is kinda pointless when they "cap" you to 250GiB
[03:20] <RAOF> Well, not really.  Burst speed is important.
[03:20]  * RAOF looks at his modem's sync page, which suggests he's getting 24Mbit down.
[03:21] <RAOF> Or would be, were caps not in effect.
[03:21] <ajmitch> RAOF: living right next door to the exchange?
[03:22] <RAOF> No idea where my exchange is; were I next door I'd be expecting a better sync, though.
[03:24] <ajmitch> better than 24Mbps?
[03:24] <ajmitch> that is the upper limit of adsl 2
[03:24] <ajmitch> s/2/2+/
[03:24]  * RAOF was under the impression 28 was the upper limit, but that may be faulty memory.
[03:26]  * ajmitch has always seen 24
[03:27] <ajmitch> of course the best I've seen at home is about 11 :)
[03:34] <calc> i can only get 3mbps here i would love any of that bandwidth even just 10mbps :)
[03:35] <calc> transferring OOo back and forth takes a long time on 3m/512k connection
[03:36] <persia> Ouch!
[03:37] <TheMuso> Ouch indeed.
[03:38] <calc> if i switched to cable modem i think i can get 6mbps maybe but then its shared bandwidth, so not sure what the effective rate would be
[03:39] <persia> My experience with shared bandwidth is that it's best practice not to try to use it when your neighbours want to use it.
[03:39]  * ajmitch is on about 7Mbps/128Kbps
[03:39] <calc> persia: heh
[03:40] <ajmitch> so uploads = slow
[03:40] <calc> ajmitch: 128kbps would be very painful for OOo :)
[03:40] <ajmitch> if I were uploading OOo, I'd be tempted to copy it to my laptop & upload from work
[03:48] <ScottK> I called my ISP earlier in the week and while I was on the phone, they said, "Oh. you have the 12/2 Mbit plan.  We don't offer that any more.  We can switch you to 25/5 for US$ 0.04 more per month."
[03:48] <ScottK> I said, "OK".
[03:48] <tbielawa> !
[03:48] <tbielawa> ScottK, FTW!
[03:49] <ScottK> So sometimes it pays to call in.
[03:59] <gnomefreak> 1993/win 20
[04:00] <persia> But what have you won lately?
[04:07] <StevenK> RAOF: I'm guessing Do caches .desktop entries. Can I make it flush it?
[04:12] <RAOF> StevenK: It only indexes .desktop entries on each start.  Quitting and starting it again will fix that.
[04:57] <wgrant> ScottK: In Australia it doesn't pay... with most major ISPs, they'll try to transfer you to the new set of plans which are vastly inferior to the one you've been on for 5 years...
[04:59] <wgrant> And what kind of connection are you on to get 5Mbps upstream!?
[04:59] <coppro> I get some obscene upstream rate on this connection
[05:00]  * wgrant has 10000/256
[05:02] <ScottK> wgrant: It's fiber all the way to the house.
[05:02] <wgrant> ScottK: Oh. I hate you.
[05:02] <ScottK> That's actually the slowest speed they offer.
[05:02] <ScottK> Well there's actual competition here now and it appears to be working.
[05:03] <jmarsden> wgrant: 10000/256 seems highly asymetrical... do you mean 1000/256 ?
[05:03] <wgrant> jmarsden: No, 10000/256
[05:04] <jmarsden> Wow, strange.  I'm not sure I've seen a connection with a 40:1 ratio like that.
[05:04] <wgrant> One would think not.
[05:06] <wgrant> The 1GB plan (we're on the 12GB one) is 10000/128
[05:07] <solarion> ScottK: where are you at?
[05:07]  * solarion is sad because he just mvoed away from a whole-city free fiber rollout.  :(
[05:07] <ScottK> solarion: Outside Baltimore, MD (USA).
[05:07] <solarion> ah
[05:07] <ScottK> solarion: Not free at all.  I have Verizon FIOS.
[05:08] <solarion> ScottK: Liberty Communications is doing the rollout in my case
[05:08] <ScottK> The trick is I have the painfully more expensive and slower version you get if you are a
[05:09] <solarion> Basically, cable brought in broadband and phone.  Instead of taking it on the chin, the little company rolled out IPTV services.  But the bandwidth was limited, so you could only have 3 set-top boxes
[05:09] <ScottK> 'business' and need static IP.
[05:09] <solarion> tehy're solving that problem now.  :)
[05:10] <ScottK> My experience with cable TV companies and ISP services is that they know a lot about cable TV.
[05:10] <solarion> I should say that the little company was the local phone company for about 3 small towns in Iowa
[05:11] <solarion> so when cable came to eat their lunch, they set out to eat the big, multi-state company's lunch.  :)
[05:11] <ScottK> Good for them.
[05:11] <solarion> they're pretty cool
[05:12] <solarion> it's very very very nice to have a small company for your isp.  Customer service isn't just lip service.
[05:12]  * solarion has at&t now and misses his old company
[05:12] <ScottK> When I called Verizon about a DNS problem last week, the first person I talked to said, "What's DNS".  It was a long day.
[05:12] <solarion> yeah, that's been my experience with AT&T
[05:12] <ScottK> Where in Iowa?
[05:13] <wgrant> ScottK: I have cable, but the cable TV provider who is also the ISP is the second-largest national telco.
[05:13] <ScottK> Eventually I got it sorted out.
[05:13] <solarion> http://www.lcom.net/switchmaxx/home.htm
[05:13] <solarion> http://www.lcom.net/switchmaxx/page.htm?page=Fiber  <- their fiber rollout page
[05:14] <solarion> ScottK: AT&T's voice recognition system is complete crap
[05:14] <solarion> but at least it's not like OG&E's
[05:14] <solarion> even the customer service rep said it's a PITA
[05:14] <nixternal> ooh, I see mad java ninjas posting to the MC list
[05:15]  * nixternal might be interested in working with the java team a bit, except for the maven bit
[05:16] <solarion> "maven bit"?
[05:16] <nixternal> ya, seems the java team enjoys maven
[05:16] <solarion> ah
[05:17] <persia> nixternal, Err, that's very much not the case.  It's rather that the java team is trying to find a way to support upstreams that enjoy maven without actually letting maven break stuff in the normal way.
[05:17] <nixternal> though once I switch the company's appliance OS from CentOS to Ubuntu, I may get to use Maven even more
[05:18] <persia> nixternal, There's a plan in place to trick maven so it can't do things the way it expects, which may be interesting to you.
[05:18] <nixternal> persia: it is hard not letting maven break stuff...that is why I am not using it with CentOS at work...we just use ant for building, and the developers for the good stuff
[05:18] <nixternal> that does sound interesting
[05:19] <nixternal> though I don't know how inclined I would be to working on Java stuff outside of work anyways...I know I am heading towards that Java meltdown :)
[05:19]  * nixternal looks for more C++ and Python projects to bring him back to earth :)
[05:19] <persia> https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec
[05:19] <solarion> what's the big difference between ubuntu server and desktop?
[05:19] <persia> solarion, Default package selection, installer interface, and contents of the CD.
[05:19] <nixternal> the server doesn't have a desktop environment :)
[05:20] <nixternal> and kernel
[05:20] <nixternal> though I don't know the differences there much
[05:20] <persia> Oh, right, and kernel.
[05:20] <persia> But still, I'd class kernel under "default package selection".
[05:20] <nixternal> true
[05:20] <solarion> so it's probably not worht re-installing then
[05:20] <solarion> just install the new packages and go
[05:21]  * solarion is repurposing an old laptop
[05:21] <persia> solarion, Depends on your goal.  If you have an old laptop, and you want a mail/dns server, reinstall might be faster.
[05:21] <persia> Then again, it's certainly less bandwidth to just install different packages.  Depends on your constraint.
[05:21] <solarion> I suppose I want to reprtition
[05:23] <nixternal> persia: the Java team going to be at UDS? If so, I will hang out with them a bit and see how that all goes...that looks like a killer spec to be honest
[05:23] <nixternal> are you going to UDS btw?
[05:23] <persia> In that case, reinstall is probably easier.  Juggling paritions on a live system is a tricky game.
[05:23] <solarion> yeah
[05:23] <persia> nixternal, Some of us will be there.  Koon won't be able to make it.
[05:23] <solarion> though since i have a root partition and two others, it wouldn't be too bad
[05:23] <solarion> boot single and monkey around a bit
[05:24] <solarion> meh, is bedtime for bonzo
[05:24] <solarion> thanks
[05:24] <persia> nixternal, Needs a *lot* of packaging work.  More hands are very welcome.
[05:24] <nixternal> groovy...I think it is time for me to go to bed..need to wake up in 4.5 hours :/
[05:24] <persia> See the bootstrapping dependencies list.
[05:24] <nixternal> YAY SNOW IN CHICAGO TONIGHT!
[05:30]  * solarion is gonna miss snow
[05:32] <sjdurfey> i installed qt4 in gnome, the designer, translator, and assistant, but the designer cant find the assistant when i try to open it, anyone know how to fix this?
[06:45] <dholbach> good morning
[06:48] <nellery> morning dholbach
[06:49] <dholbach> hi nellery
[06:55] <didrocks> morning o/
[07:37] <Laibsch> good morning
[07:38] <Laibsch> I wonder if there is a way to specify a build-time dependency as either (a AND b) OR c.  IOW, the dependency is fullfilled if either c is installed or both a and b simultaneously
[07:41] <persia> Laibsch, Not simply.  I think you'd need a package name to represent the contents of the parentheses.
[07:42] <persia> To ask differently, with which would you prefer it to build?
[07:42] <persia> (a and b) or (c)
[07:43] <Laibsch> depends on the release
[07:43] <Laibsch> I guess I'd prefer c, but that is not available in hardy
[07:44] <Laibsch> only intrepid and jaunty
[07:51] <ianm_> general question here.  I'm an app developer, and my app uses a library that's packaged at 0.23, and now 0.25 is out and it has a feature my app needs.  I contacted the package maintainer but no reply, and I see no signs that it's being updated.  what do I do?  http://packages.ubuntu.com/source/jaunty/liblo
[07:53] <persia> ianm_, liblo has *lots* of reverse dependencies, including a couple applications we routinely have difficulty building cleanly.
[07:53] <persia> I'd personally be opposed to updating it except in coordination with Debian to avoid issues.
[07:53] <persia> Debian is currently frozen for the upcoming Lenny release.
[07:54] <persia> So, from a distro point of view, I'll say "wait".
[07:54] <persia> For your specific personal use, you might want to update the app locally.
[07:54]  * persia looks for the wiki page about updating library packaging.
[07:55] <ianm_> so after Lenny, they might update it, meaning it might get into Jaunty? or +1?
[07:56] <persia> It's very likely to be updated once Lenny releases, and would then be in either Jaunty or Jaunty+1, depending on the timing of the update.
[07:56] <ianm_> the feature I need in liblo is setting the broadcast flag on a socket when the dest address is 255.255.255.255.  frustrating how hard it is to get that to end users
[07:57] <ianm_> so Jaunty+1, isn't that like a year away?
[07:58]  * ianm_ swoons
[07:58] <persia> I suspect it's more likely to be in Jaunty, but it does depend on timing.
[07:58] <ianm_> is that 9.04 ?
[07:58] <persia> Does it really need all of 0.25?  Are the changes in 0.25 small enough that a patch is useful?
[07:59] <persia> Yes.  Jaunty will be released as 9.04
[07:59] <persia> Here it is: https://wiki.ubuntu.com/MeetingLogs/devweek0809/PackageUpdates
[08:00] <ianm_> my app needs almost none of 0.25.  just this:  if (ip[0]==255 && ip[1]==255 && ip[2]==255 && ip[3]==255) { int opt = 1; setsockopt(a->socket, SOL_SOCKET, SO_BROADCAST, &opt, sizeof(int)); }
[08:02] <persia> ianm_, That's easier to apply then, although it's still likely to be Jaunty before it would be released to end-users.
[08:02] <ianm_> is it possible/OK to include a custom liblo in a PPA .deb?
[08:03] <persia> I'd recommend using either a patched version or 0.25 locally for development.  If it's not updated by 25th December, then submit a bug with a patch for the bit you need.
[08:03] <persia> No, but your PPA can contain a custom liblo.
[08:03] <persia> Of course, this may well break the other 30 applications that use liblo.
[08:03] <ianm_> it can't be the only one to use it?
[08:03] <persia> Nope.
[08:03] <ianm_> can you static link this stuff?
[08:04] <ianm_> been a while since I've done C :D
[08:05] <persia> You can static link things, but that's likely to break if there's any reason to upgrade (e.g. security fix).  Depending on how you static link, you may end up having something that usually can't be installed.
[08:08] <ianm_> hm
[08:15] <ianm_> maybe there's a way to find out the socket # and hack it
[08:25] <ianm_> persia: thanks for the advice
[10:25] <binarymutant> if anyone has any time on their hands I would appreciate a review of my package, http://revu.ubuntuwire.com/details.py?package=charm . Thanks :)
[10:32] <handschuh> binarymutant: you shuld state in the changelog what the paches do, and why they are needed
[10:32] <handschuh> s/shuld/should
[10:33] <binarymutant> good point :)
[10:36] <binarymutant> handschuh, can you see anything else wrong?
[10:36] <handschuh> binarymutant: nothing so far, but still looking
[10:36] <binarymutant> ty for taking the time
[10:37] <handschuh> binarymutant: http://revu.ubuntuwire.com/report.py/legal?upid=4035 - have you contact to upstream?
[10:38] <binarymutant> handschuh, to fix license issues and to say how much I liked the app a while ago
[10:39] <binarymutant> handschuh, I'm not sure why it reports that, it says gpl in the copyright file, and the gpl is shipped with the package now
[10:40] <handschuh> binarymutant: well, it is recommanded to add a license header to every source-file
[10:40] <binarymutant> I thought I should stay away from modifying the source
[10:41] <handschuh> binarymutant: thats why you can contact upstream to fix it  :-)
[10:41] <slytherin> binarymutant: of course you should. Upstream has to add license headers.
[10:42] <persia> For GPL, it says in the "how to use the GPL" section that license should be in every source file.  I've rejected many packages for exactly that reason, and seen others rejected by archive-admins when they were submitted.
[10:42] <binarymutant> is that policy? Because I had already bugged them to include the license in the orig tar ball
[10:42] <persia> That said, patching the files to include licensing is unacceptable.  It must be done upstream.
[10:43] <binarymutant> so this app would get rejected by debian for that? kinda sucks :/
[10:43] <sebner> persia: in debian/copyright it's -> This package is free software ... Is it a mistake when there it's $Package is free software ... ß
[10:43] <sebner> -ß +?
[10:44] <persia> sebner, Not generally a terribly important mistake.  Best to use the text from the upstream license.
[10:44] <binarymutant> well the ljcharm.py has it in there but the wrapper script charm doesn't :/
[10:44] <sebner> persia: okay, thx
[10:45] <persia> binarymutant, Wrapper scripts are sometimes exceptions, and sometimes not.  Depends on complexity, opinion of reviewers, and what the reviewing archive-admin ate for breakfast that day.
[10:45] <binarymutant> and the setup.py doesn't either...
[10:45] <persia> binarymutant, For best results, get it included.
[10:45] <handschuh> binarymutant: i am sure, upstream will be glad to receive this hint about the license
[10:46] <binarymutant> I'll try thanks for that info, hopefully she wont think i'm bugging her
[10:47] <persia> binarymutant, There's no race.  If you've passed her a patch recently, there's no harm waiting.  There's lots of other stuff to do in the meantime :)
[10:48] <binarymutant> lol k
[10:48] <handschuh> slytherin: do you have got some time to review a small java package @ http://revu.ubuntuwire.com/details.py?package=uiflite now?
[10:48] <binarymutant> is there anything else I could do to this package?
[10:50] <handschuh> binarymutant: everything else looks fine to me ... (about dpatch, I am not sure)
[10:51] <binarymutant> cool, thanks again handschuh
[10:51] <handschuh> binarymutant: have you checked the lintian of the package (binary) and the source?
[10:51] <binarymutant> yeah a bunch of times
[10:52] <handschuh> binarymutant: ok great.
[10:52] <handschuh> binarymutant: (as long as it was empty)
[10:52] <handschuh> s/was/is
[10:52] <slytherin> handschuh: not right now. I will try to find time in night, about 6 hours form now.
[10:53] <binarymutant> handschuh, the only error is the one about jaunty
[10:53] <handschuh> slytherin: ok, no problem, as persia mentioned, there's a lot other stuff to do
[10:53] <handschuh> binarymutant: thats perfectly fine
[10:54] <eMerzh> if someone has a few time to check my revu package ....http://revu.ubuntuwire.com/details.py?package=sqliteman
[10:56] <handschuh> eMerzh: take a look at http://revu.ubuntuwire.com/revu1-incoming/sqliteman-0811170000/lintian
[10:56] <eMerzh> oups :) thanks
[10:57] <handschuh> eMerzh: there is more
[10:57] <handschuh> eMerzh: your CMakeLists.txt should be modifyed by a patch
[10:58] <porthose> mounin
[10:58] <handschuh> eMerzh: debian/control: Copyright: there is no need to add the word "Copyright" before every name
[10:59] <binarymutant> persia, what about distutils should setup.py also include gpl?
[10:59] <eMerzh> ok, it's a patch bu i must understand why he apply the patch in the diff
[10:59] <eMerzh> ok
[11:00] <handschuh> eMerzh: also, explain the path in the changelog (what does the patch do and why did you add it)
[11:00] <eMerzh> ok :)
[11:01] <eMerzh> thanks
[11:02] <handschuh> eMerzh: also make sure the lintian of the binary package is empty (check with "lintian <.deb-file>")
[11:02] <persia> binarymutant, I don't usually see a GPL'd setup.py, and don't remember something being rejected for it, but I typically avoid python packages, so that may influence my experience.
[11:03] <handschuh> eMerzh: take a look at http://revu.ubuntuwire.com/report.py/legal?upid=4031 - there are some license issues that should be fixed by the upstream authors
[11:04] <binarymutant> Oh okay, then the package should be fine in the license department, I don't know why it says unknown for ljcharm.py since it's already in there. Very cool thanks
[11:07] <eMerzh> handschuh, ok i will contact upstream autor... but i must wait a new release with correct licences to re-apply to revu?
[11:09] <handschuh> eMerzh: you don't have to wait for the new upstream version
[11:09] <handschuh> eMerzh: you could reupload and post a comment, that you have contacted upstream about the licenses
[11:10] <eMerzh> Ok, great...
[11:18] <handschuh> eMerzh: should I make a summary as a comment to your package?
[11:19] <eMerzh> no , everything is noted...and work is in progress   :p
[11:19] <handschuh> eMerzh: great
[11:19] <eMerzh> thanks to you for your help
[11:20] <handschuh> eMerzh: you're welcome
[11:23] <bmm> I'm looking for my first advocate for http://revu.ubuntuwire.com/details.py?package=metalink or comments if needed :)
[11:44] <handschuh> bmm: check your legal-file at http://revu.ubuntuwire.com/report.py/legal?upid=4019 - it shows some files w/o copyright
[11:46] <DktrKranz> porthose, re slidentd merge, IIRC you noticed an issue, have you it handy?
[11:47] <handschuh> bmm: delete the commented lines of your debian/rules file
[11:47] <bmm> handschuh: I filed an upstream bug for the licenses http://sourceforge.net/tracker/index.php?func=detail&aid=2278178&group_id=148879&atid=772980
[11:47] <bmm> handschuh: ok, will do.
[11:48] <handschuh> bmm: you are not the upstream author?
[11:48] <bmm> handschuh: yes, I am :D
[11:48] <bmm> handschuh: so I should put out a new release?
[11:48]  * persia admires bmm's ability to maintain clear context separation
[11:49] <handschuh> bmm: yes
[11:49] <bmm> handschuh: ok, I'll do that then :D
[11:49] <bmm> handschuh: thanks!
[11:50] <handschuh> bmm: no problem
[11:52] <joaopinto> bmm, isn't metalink a bit too generic for a metalink file generator ?
[11:52] <handschuh> bmm: your debian/rules looks very large ... you could look at cdbs (no manditory)
[11:53] <joaopinto> since, it's a technology name
[11:53] <directhex> anyne want to take bets on how much, if any, of the hardware on my new laptop is supported in intrepid?
[11:54] <handschuh> directhex: brand?
[11:54] <bmm> joaopinto: well, it was meant as a "metalink <these files>" thing.
[11:54] <directhex> handschuh, dell
[11:54] <persia> handschuh, You might be interested in reading about debhelper 7.  It can make rules files shorter for common cases without switching to CDBS.
[11:55] <persia> directhex, Which OS is supported on your laptop?
[11:55] <handschuh> persia: didn't know that. thanks!
[11:55] <directhex> persia, formally, vista
[11:56]  * persia refuses to place a bet
[11:56] <joaopinto> bmm, I would name it something like metalink-generator, or metalink-crator, just metalink sounds more like a metalink client
[11:56] <joaopinto> ops, creator
[11:56] <handschuh> directhex: my dells hardware is fully supportet so i bet 90%  :-)
[12:01] <directhex> persia, spoilsport!
[12:05] <slytherin> directhex: I would guess 90%+
[12:05] <slytherin> directhex: you might be having problem with card reader or fingerprint reader.
[12:06] <soren> persia: Can you elaborate on the debhelper 7 making rules files shorter thing?
[12:07] <wgrant> It's like CDBS, but less bad, I hear.
[12:07] <soren> What's bad about cdbs?
[12:08] <joaopinto> CDBS is bad ?
[12:08] <directhex> slytherin, my bets are on a lack of graphics support or webcam support. AFAIK some nutter actually put the only-exists-in-an-obscure-git-tree wireless drivers onto the ubuntu kernel
[12:08]  * soren likes cdbs
[12:08] <directhex> CDBS is awkward to debug
[12:08]  * handschuh also likes cdbs
[12:08] <directhex> we use dh7 a lto in pkg-mono
[12:08] <wgrant> It can be more difficult to get it to do special things. For lots of simple things it's great.
[12:09] <persia> soren, It introduces a new command `dh` that does all the normal stuff for whichever rule is being called, as I understand it.  I've not yet created a package with it, but those I've seen were rather readable.
[12:09] <directhex> most packages start life simple ;)
[12:09] <bmm> How is the legal check performed on REVU, is that something you can run at home?
[12:09] <directhex> let me grab a pkg-mono dh7 sample
[12:09] <persia> joaopinto, Read the sendmail debian/rules.
[12:10] <soren> persia: Oh, I see now.
[12:10] <directhex> http://svn.debian.org/wsvn/pkg-mono/gluezilla/trunk/debian/rules?op=file&rev=0&sc=0 is a "complex" dh7 example
[12:10] <soren> That's rather convenient.
[12:10] <persia> Indeed, and it does it without quite so much black magic.  Still some magic, but less.
[12:10] <wgrant> persia: Put a warning in front of that sendmail suggestion next time, please. That's just evil.
[12:10]  * soren doesn't mind black magic
[12:10] <soren> :)
[12:11] <persia> wgrant, Someone asked "what's wrong with CDBS".  That's my standard answer
[12:11]  * persia is a big CDBS fan
[12:11] <persia> It's just that CDBS can get unwieldy sometimes, which gets frustrating.
[12:12] <persia> soren, I agree most of the time.  I only stopped recommending CDBS for everything after being pointed at sendmail.  There's limits to what one should try to do in CDBS.
[12:13] <soren> That is quite horrible looking indeed.
[12:13] <joaopinto> persia, would debhelper turn sendmail rules any better ?
[12:13] <slytherin> CDBS is very good for java packages. :-)
[12:14] <persia> joaopinto, That's a false question.  CDBS doesn't replace debhelper.  CDBS calls debhelper for you.  But yes, it would be tons easier to understand that rules file if it were done as a single makefile.
[12:14] <joaopinto> CDBS is very good for standard autoconf builds
[12:14] <joaopinto> persia, I mean, a non cdbs debhelper make file
[12:14] <persia> Indeed, for those anything else is likely to be buggy, although dh7 is promising.
[12:15] <persia> joaopinto, I thought so, which is why I answered in two parts :)
[12:16] <joaopinto> I just don't see why does CDBS get blamed for a complexity which is from the sendmail build/install process, not from using CDBS
[12:16] <persia> slytherin, For the 90% case, I agree, although I suspect dh7 would work as well.  It's the 10% that make non-CDBS the better choice.
[12:17] <persia> joaopinto, The point is that CDBS more quickly becomes unreadable when dealing with very complex build systems.
[12:18] <persia> Personally, I think any CDBS rules file longer than 24 lines should be redone differently, as it means that the CDBS framework isn't designed to handle your package.
[12:18] <joaopinto> well, non CDBS is harder to read simple building systems :P
[12:18] <persia> Less than 24 lines, CDBS probably makes life easier.
[12:18] <joaopinto> .. for...
[12:18] <persia> joaopinto, Is directhex's example harder to read?
[12:19] <joaopinto> persia, I am not refering to dh7, didn't tried it yet
[12:19] <sebner> Well, the shortest dh7 is:
[12:19] <persia> joaopinto, Oh, then I agree with you.  Like I said, I'm a big fan of CDBS.
[12:19] <sebner> #!/usr/bin/make -f
[12:19] <sebner> %:
[12:19] <sebner> 	dh $@
[12:19] <sebner> hehe
[12:20] <persia> sebner, Indeed, although not every package can do that.  Still, that just means "default packaging : nothing to see here : move along".  About the same as a CDBS rules file that only includes debhelper.mk.
[12:20] <sebner> persia: heh, yes. true =)
[12:21] <persia> I'd much rather see that then the mess dh_make produces.  That's just annoying, and almost everyone makes a mistake the first few times they try to determine what they need and what they don't.
[12:22] <directhex> okay, laptop report: audio works, wired network works, wireless network works, bluetooth works, graphics works (!), webcam works
[12:22] <directhex> it all bloody works out of the box
[12:22] <directhex> webcam resolution sucks though ;)
[12:22] <persia> directhex, You lose.  Time to recompile the kernel.
[12:22] <directhex> persia, to cause myself pain? o_o
[12:23] <persia> directhex, Anyway, you probably ought add that to whereever the laptop support list went.  Tell everyone else it's a good choice.
[12:23] <directhex> even the wifi killswitch works, incl. the LEDs
[12:23] <directhex> i wasn't anticipating this level of awesome
[12:24] <directhex> and the scroll-edges of the touchpad
[12:24] <handschuh> directhex: does also the bt-led works properly?
[12:25] <directhex> handschuh, yes
[12:25] <directhex> okay, i lie, the horizontal scroll-edge doesn't work. that's the only busted thing i can find
[12:25] <handschuh> directhex: you can change that in the mouse-settings
[12:25] <directhex> handschuh, you're right. that's everything then
[12:26] <directhex> handschuh, a laptop dell only started shipping a couple of weeks ago, full of bleeding edge tech, and it works 100%
[12:26] <handschuh> directhex: good thing
[12:26] <persia> directhex, If it's that new, why didn't you get it with Ubuntu?
[12:27] <bmm> directhex: I hope you don't have the Intel wireless AGN (with iwlagn driver) because then you have to keep an eye on your shutdowns :)
[12:27] <directhex> persia, too new to be sold with ubuntu
[12:27] <directhex> bmm, oh?
[12:29] <bmm> directhex: iwlagn in the current intrepid kernel seem pretty broken. Package capturing will get you allot of kernel messages and the occasional hang and shutdown with the driver and wireless still on can keep your laptop in limbo without shutting down :)
[12:30] <bmm> directhex: so if lsmod tells you you are using iwlagn, make sure you keep an eye on the shutdown process now and then ;)
[12:30] <directhex> bmm, well, did i mention "random git tree"? :p
[12:32] <bmm> directhex: I'm not getting you, but I'm also trying to do two things at one :)
[12:39] <bmm> What does "Is on m.d.n.= NO" mean? (in the context of REVUDays)
[12:40] <soren> m.d.n = mentors.debian.net
[12:42] <persia> bmm, If someone has an interest in a piece of software, and intends to keep it up to date, we encourage them to submit it to Debian, and maintain it there.
[12:42] <bmm> Ah, get it. Thanks!
[12:59] <Hobbsee> wow, canonical's supporting arm for some reason.
[12:59]  * Hobbsee didn't think arm architectures *did* mobile devices.
[13:01] <broonie> Hobbsee: Hrm? ARM is msotly mobile devices.
[13:03] <Hobbsee> broonie: oh, right.  so it is.
[13:07] <persia> Not that there's much mobile stuff in main, but with luck, at least UMPC might work for Jaunty.  MID is another matter.
[13:09] <persia> Of course, if I were in charge of the buildd scores...
[13:09] <Hobbsee> hm?
[13:10] <persia> I'm not sure I'll be able to get MID on my Zaurus from Jaunty, just because of how the buildd scores work.  Open question whether enough of universe will work for that.
[13:11] <persia> So if I was in charge of the builldd scores, I might tweak them a bit (but I don't expect the buildd admins to actually do this)
[13:15] <joaopinto> what's the nick from charliej ?
[13:15] <persia> isn't that porthose?
[13:15] <nxvl> yup
[13:16] <joaopinto> porthose, knock knock, did you install the build dependencies for the coverfinder package on revu ?
[13:17] <joaopinto> finally revu is being worked :P
[13:17] <geser> build dependencies on revu? Did I miss a new feature?
[13:17] <joaopinto> geser, no, I am asking because I got a compain about a missing dpatch file, when dpatch is on the build depends for the package
[13:18] <geser> ah
[13:18] <joaopinto> s/compain/comment
[13:19] <joaopinto> an offtopic questions, is there any way to force the dns lookups to be performed on the alternate servers even if the first one replies with not found ?
[13:20] <joaopinto> I need to have two dns servers, internet and lan, both working at the same time
[13:21] <persia> Probably best to have the local one handle everything, caching and forwarding the rest.
[13:21] <joaopinto> hum, I don't have acces to any of the servers, you you mean installing a local dns server and setting it up for that ?
[13:22] <joaopinto> basically I would need to use a dns server based on the domain, there should be an easy way to do it from resolv.conf
[13:23] <joaopinto> if server.matches("domain.com") use dns.domain.com :P
[13:25] <joaopinto> on windows I have this dual dns configuration working fine
[13:25] <geser> joaopinto: re coverfinder: I gave it now a very quick review: do you really need to include dpatch.make and dpatch.mk in debian/rules? Please remove README.Debian if you have no content for it and also mention the license (and upstream author) for the icon (the one from the package)
[13:26] <joaopinto> geser, no, I don't need both, i need to clean it up
[13:26] <joaopinto> geser, could you post on the comments, just for the sake of workflow and to do list :)
[13:26] <joaopinto> I am not "on hands" with the package right now :\
[13:31] <geser> joaopinto: done
[13:32] <joaopinto> geser, tks
[14:03] <Koon> kirkland: I've submitted a couple of universe merges you might be interested in sponsoring... since they also fix the corresponding "status" initscript action. See bug 298043 and bug 296080
[14:03] <Koon> hrm. I mean bug 298080.
[14:03] <kirkland> Koon: awesome, i'll definitely review for you!
[14:04] <Koon> kirkland: btw, is it still necessary to push a lsb-base dependency for the jaunty cycle ? Or we can assume it's present ?
[14:05] <mok0> ogra, ping
[14:05] <kirkland> Koon: hmm, it's probably "proper" to add that dependency
[14:05] <Koon> kirkland: that's what ... I did
[14:05] <kirkland> Koon: cool
[14:06] <kirkland> Koon: I'm still working through my inbox this morning, can I review as soon as I'm on top of that?
[14:06] <Koon> kirkland: sure, no hurry at all. and thx
[14:06] <ogra> mok0, yes ?
[14:07] <mok0> ogra: You looked at rasmol last, but I think we can sync instead of merge
[14:07] <ogra> go ahead if you feel like
[14:07] <mok0> ogra: ok, thanks
[14:07] <ogra> i only did an upload for LaserJock iirc
[14:08] <ogra> he knows more about it than i do
[14:08] <mok0> ogra: ah, ok. The only delta is the maintainer-munge
[14:08] <ogra> yeah, sounds like a sane sync candidate then
[14:08] <mok0> ogra: I think so too :-)
[14:09] <mok0> ogra: I will process it
[14:09] <ogra> great, thanks :)
[14:40] <eMerzh> I'm looking for a review ( http://revu.ubuntuwire.com/details.py?package=sqliteman )...if someone could see it... :)
[14:42] <verwilst> asac: ping
[14:42] <verwilst> any reason why nspluginwrapper has 1.1.0 for i386 and 1.1.2 for amd64?
[14:43] <asac> verwilst: not really. would be bug i guess
[14:43] <verwilst> because 1.1.4 is out, so i would try to package it for my ppa
[14:44] <verwilst> and then try to package flashplugin-nonfree for amd64 as well :)
[14:44] <mok0> ugh. Is there a good way to make sbuild cache the packages it get s from the archive?
[14:45] <persia> mok0, Use an apt-proxy.
[14:45] <geser> asac, verwilst: P-a-S lists it as amd64 only
[14:45] <verwilst> asac: my flash is still rather unstable with nspluginwrapper and flash 10, a lot of times, flash just shows a gray area
[14:46] <mok0> persia: Thanks I will look into that!
[14:46] <verwilst> which is fixed in 1
[14:46] <verwilst> in 1.1.4*
[14:46] <verwilst> i think :)
[14:46] <verwilst> P-a-S?
[14:46] <verwilst> hm, so 1.1.0 is i386 only, and 1.1.2 is amd64-only?
[14:46] <geser> Packages-arch-Specific, a list which packages should be only build on some specific archs
[14:47] <geser> the buildds try it only to build on amd64 (it might even work on i386)
[14:47] <geser> but the archive still has the old i386 deb
[14:49] <persia> There's a bug about that.  The archive-admins don't have very good tools to find packages that are dropped for only some architectures and should be removed from the archive.
[14:57] <asac> thats really strange
[14:57] <asac> persia: but how comes that 1.1.0 was built for i386
[14:57] <asac> ;)
[14:57] <asac> and 1.1.2 wasnt
[14:58] <asac> seems like someone tried to be _too_ smart ;)
[14:59] <persia> asac, I suspect P-a-s permitted i386 for 1.1.0, and then dropped it when 1.1.2 didn't compile.
[14:59] <verwilst> so, for jaunty we should have 1.1.4 for both archs, correct? ;)
[14:59] <asac> persia: huh?
[14:59] <verwilst> i can build it in my ppa to test?
[14:59] <persia> For some packages I've found binaries from the warty build that were never rebuilt despite regular updates to the package due to poorly timed P-a-s changes.
[15:00] <asac> persia: 1.1.0 + 1.1.2 was built during intrepid
[15:00] <persia> asac, OK.  If a package builds, it stays in the archive until manually removed.
[15:00] <persia> So, when was the P-a-s entry changed?
[15:00]  * persia is fairly sure it was after 1.1.0 was uploaded.
[15:00] <asac> persia: not sure. nobody asked me about it
[15:00] <directhex> with flash 10 64-bit, what still needs nspluginwrapper?
[15:00] <asac> persia: and it was never intended to be blocked from i386
[15:01] <verwilst> directhex: i think nspluginwrapper is used to catch flash crashes
[15:01] <persia> asac, Remember we share P-a-s with debian, so it could have been intended to be blocked in Debian.  Check with the P-a-s team.
[15:01] <directhex> verwilst, s/catch/cause, but same difference
[15:01] <verwilst> that way it only crashes nspluginwrapper and not the browser itself
[15:01] <asac> *sigh*
[15:01] <asac> how dump
[15:01] <asac> dumb
[15:01] <persia> why?
[15:02] <verwilst> directhex: hehe, true, nspluginwrapper causes quite some crashes by itself
[15:02] <verwilst> im now running the x86_64 alpha flash 10 without nspluginwrapper to check its stability :)
[15:02] <directhex> verwilst, my browser currently dies ~10 times a day due to nspluginwrapper, and some sites are unusable - e.g. thedailyshow.com nspluginwrapper instances all die by the time the page finishes loading
[15:03] <verwilst> directhex: with the gray squares as a result?
[15:03] <directhex> verwilst, aye
[15:03] <verwilst> directhex: that bug should be fixed in 1.1.4 :)
[15:03] <verwilst> i have the same issue :)
[15:03] <directhex> verwilst, i'll believe it when i see it
[15:03] <asac_> reconnect
[15:04] <asac_> 16:03 < asac> persia: why? because i explicitly enabled i386 during intrepid cycle
[15:04] <asac_> 16:03 < asac> and then someone added it to pas
[15:04] <verwilst> but still, i don't like yet another layer that can mess up inthere
[15:04] <asac_> and of course i didnt notice until today when someone complained
[15:04] <asac_> thats your choice ... and its completely independent
[15:04] <asac_> from blocking stuff on i386 ;)
[15:05] <persia> asac, Ah.  I see.  Yeah, interaction with P-a-s can be tricky.
[15:05] <directhex> verwilst, on my hardy machines i simply gave up & used a 32-bit tarball browser. tempted to do the same on intrepid, until this shining light from adobe appeared
[15:05] <asac> directhex: not sure if flash can ever be a shining light
[15:05] <asac> directhex: we need nspluginwrapper 1.1.4
[15:05] <asac> problem with 1.1.2 and before was that upstream was long dead
[15:06] <asac> until redhat bugged personally hunt him down
[15:06] <directhex> asac, never had moonlight crash my browser ;)
[15:06] <asac> directhex: does moonlight run "in browser" ?
[15:06]  * verwilst gasps
[15:06] <directhex> asac, sure.
[15:07] <asac> directhex: but still its not a heavily used technology so it doesnt say anythignb ;)
[15:07] <verwilst> directhex: you actually know sites which use it? :)
[15:07] <directhex> well, there is that
[15:07] <directhex> but at least it *fails to work* on sites, rather than actively screwing your computer
[15:08] <verwilst> so why can't we leave out nspluginwrapper for flash 10?
[15:09] <directhex> verwilst, because 64-bit flash 10 was only posted, in alpha form, this morning
[15:10] <verwilst> myeah but for i386
[15:24] <verwilst> directhex: so if flash 10 is final for both platforms, nspluginwrapper can be removed?
[15:24] <verwilst> what's the "official" stance about this?
[15:24] <verwilst> or the bigger picture :)
[15:24] <directhex> ask asac!
[15:24] <asac> no
[15:25] <asac> the bigger picture is that we want to keep nspluginwrapper
[15:25] <asac> flash was never really stable, while nspluginwrapper was .... now nspluginwrapper has some hick-ups mostly because of windowless support
[15:25] <asac> but that will be sorted and then it will properly protect you against ffox crashes
[15:33] <asac> verwilst: of course when it natively supports amd64 we will demote nspluginwrapper to suggests/recommends or something
[15:38] <verwilst> asac: nice
[15:38] <verwilst> asac: i guess i386 is using nspluginwrapper as well now just to keep the 2 archs in sync
[15:39] <asac> no .... to as i said. it exists to guard ffox from flash crashes
[15:39] <asac> i dont want to run flash without it
[15:39] <verwilst> hm
[15:39] <asac> and once all current issues are sorted almost everyone wants flash to use it
[15:39] <verwilst> it causes more crashes here than flash itself currently :)
[15:40] <verwilst> but maybe 1.1.4 will fix that
[15:40] <asac> verwilst: I already talked about that above
[15:40] <asac> disabling windowless mode will probably fix most crashes for you
[15:40] <verwilst> oh sorry, must have missed that
[15:41] <verwilst> your name is just so light here, can barely read it ;)
[15:41] <asac> http://paste.ubuntu.com/73375/
[15:41] <asac> verwilst: irssi in terminal?
[15:41] <verwilst> asac: pidgin :)
[15:41] <asac> cant help there ;)
[15:41] <asac> should be readable
[15:41] <verwilst> hehe
[15:42] <asac> at least you can probably fix it in UI
[15:42] <verwilst> well it's readable.. but it's a very light blue-ish
[15:42] <verwilst> easy to overlook :)
[15:42] <asac> just look for the empty spots ;)
[15:42] <verwilst> anyways, what does that windowless stuff do?
[15:42] <verwilst> (practically :) )
[15:45] <verwilst> i think the "Fix XEMBED support" will fix a lot of my issues
[15:45] <verwilst> since most of the time i just see grey squares
[15:46] <verwilst> and only a full firefox restart can get me my flash back then :)
[16:10] <handschuh> slytherin: ping
[16:12] <emgent> omg i love adobe.. libflash 64bit is out..
[16:19] <eMerzh> if someone has again some times to re-review my package :p (http://revu.ubuntuwire.com/details.py?package=sqliteman)
[16:23] <NCommander> wow
[16:23] <NCommander> wait
[16:23] <NCommander> 64-bit flash plugin?
[16:23] <NCommander> O_O!
[16:23]  * NCommander thinks he sees hell freezing over
[16:23] <hyperair> NCommander: WHERE
[16:24] <NCommander> Holy ****
[16:24] <NCommander> I found it
[16:24] <NCommander> http://labs.adobe.com/downloads/flashplayer10.html
[16:25] <jrib> emgent: you "love adobe" ?  Why?
[16:26] <hyperair> ...oh my god
[16:27] <NCommander> 64-bit plugin O_O;;
[16:27] <jrib> meh
[16:27]  * hyperair seriously considers trying out ubuntu x64
[16:27] <NCommander> It works
[16:27] <NCommander> O_O;
[16:29] <jrib> haha crashed my epiphany
[16:30] <handschuh> I get a great segmentation fault
[16:31] <jrib> yup
[16:32] <jrib> crashes on some flash.  Google video seems to do it
[16:32] <NCommander> It works great here for me
[16:32]  * NCommander submits to Slashdot
[16:32] <jrib> NCommander: http://video.google.com/videoplay?docid=-5122859998068380459&hl=en
[16:33]  * jrib puts nsplug to work again
[16:33] <NCommander> Works fine here
[16:33] <NCommander> jrib, ^
[16:34] <NCommander> I thought Google Video was defunct
[16:44] <james_w> Koon: are you not a MOTU yet?
[16:44] <Koon> james_w: heh... no.
[16:44] <james_w> Koon: please consider applying :-)
[16:44] <Koon> james_w: I decided to suck up sponsor time a little more :)
[16:45] <Koon> james_w: I do. Should be applying really-soon-now[tm]
[16:47] <james_w> great
[16:49] <james_w> Koon: I'm looking at pure-ftpd, I see you forwarded the status change, thanks. Have the other things applicable to Debian been forwarded? I can't see them in a quick scan of the bug list.
[16:50] <hyperair> in the case of cdbs, does install: get called before or after dh_install does?
[16:50] <hyperair> install:: i mean
[16:51] <Koon> james_w: the RFC2640 stuff and the wrapper options are already filed
[16:52] <persia> hyperair, The named overrides run after the internals.  You probably want to read the "Custom Overrides" part of the CDBS documentation again.
[16:52] <hyperair> persia: thanks
[16:52] <james_w> Koon: cool. It would be nice to file TearDown and /var/run/ as well
[16:53] <Koon> james_w: does debian take TearDown patches ?
[16:53] <james_w> Koon: I'm in the process of sponsoring anyway, it doesn't look well maintained
[16:53] <james_w> Koon: they will.
[16:53] <james_w> Koon: implemented the way you have, not the old "multiuser" way
[16:54] <hyperair> persia: so if i do install/foo:: should i be modifying debian/foo or debian/tmp?
[16:54] <james_w> Koon: I can dig out a link to the debian-devel@ discussion if needed
[16:54] <persia> hyperair, I can't answer that question without a *lot* more background information.  Test it and see.
[16:54] <Koon> james_w: about /var/run, I was about to file it when I found that there was something in debian/rules that was creating the directory... so that patch mught be overkill
[16:55] <hyperair> persia: it's one hell of a long build, so i'd rather get it right on the first try ><
[16:55] <persia> Koon, Some people run /var/run as tmpfs even in Debian.  It's worth checking for existence and creating if absent at runtime (which is safe when installed in any case)
[16:56] <Koon> persia: ah ok, thanks for pointing that out.
[16:56] <persia> hyperair, In that case, read the documentation, and note in which categories your package falls to determine the right names.
[16:56] <persia> Koon, Just do it with an existence test, and don't wipe it if it's there to avoid stomping on the default Debian config.
[16:56] <hyperair> persia: ..which part. i've read it over and over and i still can't figure out whether i'm supposed to modify debian/tmp or debian/foo
[16:57] <persia> I forget :(
[16:57] <Koon> james_w: I'll push the two bugs tomorrow morning. And yes, I could use a link to a debian-devel post to justify the TearDown bug
[17:02] <Koon> james_w: I'll also push a wishlist bug for the debconf preference. The last one is a *inetd* Suggests that should probably be dropped if it's the only remaining delta.
[17:02] <james_w> http://lists.debian.org/debian-devel/2008/08/msg00030.html
[17:02] <james_w> http://lists.debian.org/debian-devel/2008/07/msg00198.html
[17:03] <Koon> james_w: noted, thx !
[17:04] <james_w> there's not really one mail that you can reference to give the whole picture
[17:04] <Koon> it's just to show the potential maintainer (?) it's not an Ubuntu-only thing :)
[17:04] <james_w> "there was a discussion on debian-devel and no-one came up with a good reason not to" is kind of my justification
[17:05] <james_w> anyway, uploaded, thanks for your contribution
[17:05] <Koon> and thanks for uploading :)
[17:06] <Koon> back tomorrow for more adventures.
[17:14] <webtech_m33> so who takes care of mailscanner?
[17:19] <mok0> james_w: I watched your video tutorial on bazaar packaging last night. Nice!
[18:05] <joaopinto> can someone nuke the coverfinder package on REVU ?
[18:06] <slytherin> joaopinto: what happened?
[18:07] <joaopinto> slytherin, lost the interest on it
[18:07] <slytherin> :-)
[18:08] <joaopinto> I am going to finish amoebax, then pick a more usefull package, maybe lives
[18:10] <bddebian> Heya gang
[18:11] <slytherin> joaopinto: ping NCommander or RainCT for nuking the package.
[18:11] <joaopinto> ok
[18:15] <geser> Hi bddebian!
[18:16] <slytherin> bddebian: geser: hi
[18:17] <bddebian> Heya geser, slytherin
[18:18] <geser> Hi slytherin
[18:18] <slytherin> can anyone help me modify this watch file so that it matches OmegaT_x.y.z_Source.zip but not OmegaT_x.y.z_Beta_Source.zip - http://paste.ubuntu.com/73423/
[18:20] <joaopinto> does anyone know if there is a tool which allows to stream a terminal session to a web page ? I mean, something text based, not a video streamer
[18:20] <joaopinto> it would be nice for packaging lessons
[18:24] <bddebian> slytherin: OmegaT_([\d.]+)_Source.zip
[18:24] <slytherin> bddebian: let me try
[18:25] <slytherin> bddebian: should it be [\d\.] instead of [\d.]?
[18:26] <geser> no, . looses its special meaning inside []
[18:26] <slytherin> ok
[18:27] <joaopinto> can someone review/advocate http://revu.ubuntuwire.com/details.py?package=amoebax ?
[18:27] <slytherin> I get - no matching hrefs for watch line :-(
[18:30] <handschuh> slytherin: I updated the comments @ uiflite .. take a look whenever you want to  :-)
[18:31] <slytherin> handschuh: some confusion, is it related to -looks or -forms?
[18:31] <handschuh> slytherin: just the author is the same person
[18:32] <bddebian> slytherin: Though you do need: OmegaT_([\d.]+)_Source\.zip
[18:33] <slytherin> handschuh: I mean, I asked why you can't update jgoodies-looks and you reply that it has nothing to do with jgoodies-forms. So I am confused.
[18:33] <slytherin> bddebian: that shouldn't make difference in this case.
[18:34] <handschuh> slytherin: indeed is has (programatically) nothing to do with forms or looks
[18:34] <slytherin> bddebian: I did that change and it works. Now I am wondering if previous error was due to connection problem.
[18:34] <handschuh> slytherin: the author has a commercial uif-package, and uiflite contains some recources of it
[18:35] <slytherin> handschuh: hmm, can you talk with upstream and see if the author is willing to make a separate source package. I mean what happens if in future he stops publishing it as part of -looks.
[18:35] <handschuh> slytherin: ok I will do that
[18:36] <slytherin> bddebian: looks like last error was indeed due to connection problem.
[18:41] <slytherin> any shell script used by get-orig-source target should have execute permissions, right?
[19:06] <iulian> james_w: Hey. About the svk merge... I don't really get what you mean. The 'intrepid patch' from bug #292793 was already uploaded to Debian.
[19:07] <iulian> Sorry, it's bug #282793
[19:07] <iulian> Bleah
[19:07] <iulian> https://bugs.edge.launchpad.net/ubuntu/+source/svk/+bug/282793
[19:09] <james_w> iulian: you need to re-do the merge to include the new jaunty changelog entry
[19:09] <james_w> and while doing that I would like you to take the time to double check the fixes
[19:10] <james_w> debian said "libfile-temp-perl has been merged into perl, remove dependency.", Michael said "I had to upload a modified debdiff that depended on perl, vs perl-modules (which is the correct fix). "
[19:10] <james_w> without looking at diffs there appears to be a bit of a discrepancy there
[19:10] <james_w> I would like you to confirm that no mistakes were made
[19:11] <directhex> woo, we're 1/3 of the way there
[19:12]  * jdong looks at firefox 3.0.4 backport
[19:12] <jdong> let's see if I can get it out <= 24hrs of -security :)
[19:13] <iulian> james_w: I'm pretty confused. I have no idea why he mentioned about perl-modules. The debdiff he uploaded doesn't mention anything about perl-modules. The debdiff is pretty the same as the one which is already in Debian.
[19:14] <NCommander> jdong, did I hear backport?
[19:14] <slytherin> jdong: backport to which Ubuntu version?
[19:14] <directhex> sideport!
[19:14] <iulian> james_w: I'll re-do the merge to see exactly what's going on.
[19:15] <jdong> slytherin: gutsy
[19:16] <jdong> gutsy-backports has a special side-by-side install version of firefox-3.0
[19:16] <slytherin> ahh
[19:16] <jdong> I felt bad for leaving it at 3.0~beta3 for several months before 3.0.3 so this time I'll make up for it with a responsive backport :)
[19:16] <slytherin> :-)
[19:17] <NCommander> jdong, wait, sideport? How'd you do that?
[19:17] <jdong> NCommander: coordination with the Mozilla team :)
[19:17] <jdong> NCommander: based off the old sideport packaging in gutsy of what used to be trunk at the time.
[19:17] <joaopinto> NCommander, can you please nuke the coverfinder packager on REVU ? Thanks
[19:18] <NCommander> jdong, I mean with a sideport, did you backport it as a new source package or?
[19:18] <jdong> NCommander: firefox-3.0 source packages already existed in gutsy (non-backports)
[19:18] <NCommander> ah
[19:18] <jdong> they were just really really really old snapshots
[19:18] <jdong> I made it a lesser and lesser old snapshot
[19:18] <jdong> then ff-3.0 became the default in Gutsy
[19:19] <jdong> so I cherry-unpicked out the changes that made it the default
[19:19] <ScottK> jdong: Hardy
[19:19] <jdong> sorry, meant to say hardy
[19:22] <eMerzh> i m looking for comments or advocate for sqliteman thanks a lot (http://revu.ubuntuwire.com/details.py?package=sqliteman )
[19:23] <james_w> iulian: I agree, the changelog entry is confusing. Please just propose a new diff including the jaunty changelog entry
[19:23] <joaopinto> can someone review/advocate http://revu.ubuntuwire.com/details.py?package=amoebax ?
[19:23] <james_w> NCommander: your svk changelog entry clouded the issue, as it states you did something different to what you actually did.
[19:24] <NCommander> james_w, I'm aware of that :-/. I did originally do what I did w/ svk, then I changed it and forgot to update the changelog.
[19:24] <NCommander> before I uploaded
[19:25] <james_w> iulian: also, when merging something that fixes an Ubuntu bug please don't add the "LP: #21345" to the "Merge from Debian" line, it's not very clear about what is going on. Please instead add a line explaining how the bug was fixed and add the "LP:" there.
[19:26]  * slytherin starts a pbuilder build for omegat and ends the day.
[19:31] <iulian> james_w: OK. I now don't have to mention bug 282793 in the changelog anymore, is this correct?
[19:31] <james_w> iulian: correct, just a bit of advice for the future
[19:31] <iulian> Sure, thanks.
[19:33] <jdong> oh WHAT THE **** TAR.
[19:33] <jdong> that's just unfair.
[19:33] <jdong> did anyone else know that tar checks whether or not you are writing to /dev/null?
[19:33] <jdong> and if so, it only does enough work to print out the filelist?
[19:35] <iulian> james_w: I just mention the bug I reported to the "Merge from debian" line?
[19:36] <iulian> james_w: And again, in this case I believe is not worth it.
[19:36] <james_w> iulian: just list your merge bug in the "Merge from Debian" line
[19:36] <iulian> Right
[19:37] <james_w> any other Ubuntu bugs fixed in Debian in the version you are merging should get their own line
[19:37] <iulian> Yup
[19:53] <directhex> okay, i wasn't completely correct - i have a completely screwed text console on this dell. i'll try vga= lines
[20:07] <didrocks> Hi everyone. I have a merge that fixes two LP bugs. I added it in the changelog next to the revelant lines (java-wrappers accordingly. (LP: #280433, #229032)) which is a "debian change". Is it correct? cf http://ubuntu.pastebin.com/m284c4256
[20:09] <iulian> james_w: I attached the debdiff to the bug report. Please test it to see if the package installs correctly because when I try to apt-get build-dep svk here, it gives me an error (E: Build-Depends-Indep dependency for svk cannot be satisfied because no available versions of package libfile-temp-perl can satisfy version requirements).
[20:09] <iulian> james_w: Looking at debian bug 497130 it seems that libfile-temp-perl
[20:10] <iulian> ... is provided in perl-modules.
[20:12] <ScottK> iulian: It is.
[20:12] <iulian> We already depend on perl >=5.10 which is provided in perl-modules. So that shouldn't be a problem.
[20:13] <ScottK> iulian: You to build-dep on perl-modules directly IIRC.
[20:13] <ScottK> There's a versioned provides issue in sbuild.
[20:13] <iulian> ScottK: Do you recommend to build-dep on perl-modules?
[20:14] <NCommander> ScottK, I thought you just build-dep on Perl
[20:14] <NCommander> That's what I did to fix svk
[20:14] <ScottK> Dunno.  Look at the Intrepid changes for https://launchpad.net/ubuntu/+source/mime-tools
[20:14]  * ScottK is on the phone.
[20:15] <iulian> NCommander: Well, I tried that but it seems that is not working, see the above error.
[20:15] <joaopinto> can someone review/advocate http://revu.ubuntuwire.com/details.py?package=amoebax ?
[20:15] <ScottK> That's the same issue fixed in that package.
[20:15] <iulian> I wonder how nxvl got it working.
[20:16] <didrocks> … so, can I assume that mentionning the LP bug numbers next to the debian description is correct in case of merge? :)
[20:19] <iulian> james_w, NCommander: Should we add a build-dep on perl-modules as well?
[20:19] <NCommander> iulian, you shouldn't have to perl depends on perl-modules O_o;
[20:19] <iulian> Well, yea, you're right but why it didn't work?
[20:20] <iulian> Hmm
[20:21] <NCommander> Strange
[20:22] <directhex> gah. summon the fail whale!
[20:22]  * NCommander raises his hands. The whale falls on directhex 
[20:23] <directhex> NCommander, let's say you had a laptop. if you just let intrepid boot, then it looks fine from start to finish, until you hit ctrl-alt-f1, at which point you see nothing bit sparkly garbage until you go back to ctrl-alt-f7
[20:23] <directhex> NCommander, alternatively, you set a vga=foo line in menu.lst - which fixes the consoles, but makes usplash look like ass
[20:23] <NCommander> o_o;
[20:24] <directhex> a 1280x800 console looks nice - a stretched, glitchy usplash does not
[20:24] <joaopinto> NCommander, can you nuke coverfinder from REVU ?
[20:24] <NCommander> joaopinto, link
[20:24] <joaopinto> http://revu.ubuntuwire.com/details.py?package=coverfinder
[20:25] <NCommander> joaopinto, why do you want it nuked?
[20:25] <joaopinto> NCommander, because I am no longer interested in packaging it
[20:26] <NCommander> Ok, fair enough
[20:26] <NCommander> joaopinto, nuked
[20:27] <joaopinto> tks
[20:27] <directhex> NCommander, now, as best i can read it, usplash ought to be overridable either by having a widescreen theme (which identifies itself as wide), or by forcing some usplash params on the command line (where?!)
[20:27] <NCommander> directhex, you can set the resolution it needs in /etc/usplash.conf
[20:28] <directhex> see, why isn't that file in the SEE ALSO of "man usplash"?
[20:28] <NCommander> directhex, file a bug
[20:28] <directhex> i shall!
[20:31] <directhex> okay, so it still looks bolloxed if i set 1280x800 in the file and a 1280x800 console
[20:31] <directhex> perhaps 1024x768 works
[20:33] <directhex> okay, if usplash.conf is smaller than vga=, then it works, but is offset a little. that's the best i've had so far
[20:34] <directhex> i get my high-res text consoles, and usplash looks normal. if swinging a bit to the left
[20:36] <directhex> sigh. i really don't want to work on a C-based app, but usplash clearly needs LARTing
[20:49] <iulian> Hmm, when you apt-get build-dep $pkg, you'll install all build-dependencies of the package from the current version.
[20:50] <iulian> So when I apt-get build-dep svk, I'll install libfile-temp-perl as well.
[20:50] <leonel> ScottK: I'll make a single debdiff  with  a entry for every patch in debian patches   but ..  I'm missing how to name the possible CVE that we are fixing
[20:50] <iulian> Perhaps this explains why I got that error.
[20:50] <iulian> NCommander, james_w: ^^
[20:51] <james_w> iulian: it uses information from the Sources.gz
[20:51] <NCommander> iulian, if this is SVK,I don't think its been accepted intoupdates yet
[20:51] <james_w> I don't know if it uses it from the installed package as well
[20:54] <iulian> Yup, so I still install libfile-temp-perl when I run that command. I'm trying to install the build-deps manually and seeing if I can get it to work.
[20:55] <jcastro> ok, who here is a relatively new contributor who has sent patches upstream?
[20:56] <jcastro> looking for a volunteer!
[21:00] <ScottK> leonel: I don't know that there are CVEs for these.  You might look in the debian/changelog of Debian's updates for Etch.
[21:01] <leonel> ok
[21:02] <leonel> if there's no cve I'll name the  patch
[21:02] <leonel> thanks
[21:02] <ScottK> That's good.
[21:03] <iulian> NCommander: Oh, no, it's hasn't been accepted into -updates yet, even though the bug had the 'Fix Released' status.
[21:03] <NCommander> iulian, its fixed release in Jaunty
[21:03] <NCommander> Intrepid is still marked "In Progress"
[21:04] <iulian> NCommander: No, it wasn't. Someone marked it as "Fix Released".
[21:04] <iulian> See the activity log.
[21:05] <NCommander> Strange
[21:05] <NCommander> Whoever did shouldn't have
[21:05] <iulian> Indeed.
[21:08] <joaopinto> can someone review/advocate http://revu.ubuntuwire.com/details.py?package=amoebax ?
[21:08]  * iulian yawns
[21:09] <iulian> james_w: Yaay! It worked. Feel free to upload now.
[21:10] <Yasumoto> Hey guys, question about changelogs + merges: Should I just copy-paste the changes from the -ubuntu1 to ubuntu-x versions, then check each to see if they're in the plain debian packages?
[21:10] <james_w> iulian: done, thanks.
[21:12] <iulian> james_w: OK, we'll now just need the 2nd ACK which is the final one from a SRU member.
[21:13]  * iulian looks for a SRU member.
[21:20] <mok0> I am writing a watch file, but the remote web server does not allow read access to the src directory where the sources are stored. Any tips on how to work around this?
[21:21] <handschuh> mok0: could you give us the project url?
[21:21] <mok0> http://www.theseus3d.org/src
[21:22] <mok0> You see, uscan can't fetch the list of available tarballs
[21:22]  * james_w wants Thierry to become a MOTU so that no-one has to sponsor tomcat :-)
[21:23] <handschuh> mok0: well even if you could, the download does not contain any version number
[21:28] <handschuh> mok0: so I think the only thing you could do is write the get-orig-source rule with a fixed version-number
[21:28] <handschuh> :-/
[21:33] <mok0> handschuh: I have written to upstream asking him to put a href to the versioned tarball in index.html
[21:34] <handschuh> mok=: oh, of course that would be the best! good luck
[21:34] <mok0> handschuh: thx
[21:34] <handschuh> s(=/0
[21:38] <mok0> james_w: I'd like to take a look at the lvm2 repo that you "play" with in the video. Where is it published?
[21:38] <mok0> james_w: I am interested in seeing how the branches are organized
[21:40] <mok0> handschuh: what's the status of ballontips?'
[21:40] <kumy> hi, can someone revu my frogd package ? It's available there http://revu.ubuntuwire.com/details.py?package=frogd . frogd is a daemon for Unix systems to use the Froggy temperature and humidity sensors sold on http://www.froggyhome.com. I've also written & included few patches. thanks in advance ! :)
[21:41] <james_w> mok0: it's published nowhere currently
[21:42] <handschuh> mok0: it has been accepted by motu!  :-)  its currently also in the debian mentors queue
[21:42] <handschuh> mok0: thanks again for your patience
[21:43] <mok0> james_w: ah. I need some more basic info on packaging using bzr, there are some things still not clear to me
[21:43] <mok0> handschuh: congrats! Your first package in Ubuntu!
[21:44] <mok0> kumy: I will take a look
[21:44] <handschuh> mok0: thanks. hopefully not the last one (there is already a new one at revu, but there is a question to discuss with upstream first)
thanks!
[21:45] <kumy> mok0
[21:46] <jimcooncat> can someone point me to a good howto on gpg signing my personal repository? My googling's getting me nowhere on this.
[21:46] <mok0> kumy: Whoa, french version of the GPL, never seen that before :-)
[21:49] <mok0> kumy: why is the clean target disabled?
[21:49] <kumy> mok0: in source isn't it ? is it a problem ?
[21:50] <kumy> mok0: because it conflics with patchsys-quilt.mk
[21:50] <mok0> kumy: you need the clean target to avoid crud in diff.gz
[21:50] <mok0> kumy: how "conflicts"?
[21:52] <joaopinto> can someone review/advocate http://revu.ubuntuwire.com/details.py?package=amoebax ?
[21:53] <joaopinto> I need to setup a timer for this
[21:54]  * handschuh is reviewing
[21:55] <joaopinto> handschuh, tks
[21:57] <iulian> joaopinto: I see that the upstream tarball comes with a .desktop file. Why don't you patch and use it instead of creating another one yourself?
[22:00] <joaopinto> hum, I don't remember seeing a .desktop file on the beginning
[22:01] <iulian> joaopinto: It's in the data/ dir.
[22:01] <joaopinto> is it mandatory to use a patch system ?
[22:02] <iulian> joaopinto: You're not allowed to change anything outside debian/.
[22:02] <joaopinto> iulian, I am referring to keep the change on the build diff.gz
[22:03] <joaopinto> the last time I have read the wiki, using a patch system was recommended but not mandatory
[22:04] <joaopinto> actually I should have sent the new desktop file to upstream :\
[22:05]  * handschuh has also commented sth on joaopintos package
[22:05] <iulian> It's good that the upstream comes with a .desktop file. If I was you, I would have patched the .desktop file, send it upstream and then drop in my next upload.
[22:05] <iulian> joaopinto: Yes, please do.
[22:06] <mok0> kumy: Do you really need to use debconf?
[22:06] <joaopinto> but well, for now, to get the package ready, I am going to patch it
[22:07] <kumy> mok0: it's not really important... default values should work fine, but some parameters needs to be personalized like current altitude, or connected serial port...
[22:07] <joaopinto> handschuh, didn't understood the "4) debian/amoebax.xpm
[22:07] <joaopinto> Deliver this file as a patch if its not in the upstream version. "
[22:08] <joaopinto> what is wrong on providing the xpm on /debian ?
[22:09] <handschuh> joaopinto: its the same as iulian said: you are not allowed to add files outside of the debian dir
[22:09] <mok0> kumy: I understand...
[22:09] <joaopinto> handschuh, the .xpm is not outside the debian/ folder
[22:09] <handschuh> joaopinto: oh sorry - i missed that
[22:09] <joaopinto> :P
[22:10] <mok0> kumy: personally, I dislike being asked stuff when upgrading and installing
[22:10] <joaopinto> the .desktop does make sense because I duplicating upstream with a fixed version
[22:10] <iulian> joaopinto: You have the .xpm icon in the debian/ directory but I see data/amoebax.svg usr/share/pixmaps
[22:10] <ScottK> Questions should only be absolutely needed ones.
[22:12] <kumy> mok0: yes, but you may have to personalize it the first time... it could also be the user resposability to think about that. i'm open, what the best way ?
[22:13] <mok0> kumy: let's not worry about that, for now
[22:13] <kumy> mok0: ok
[22:16] <iulian> joaopinto: Ah, right, the tarball does not come with a .xpm icon.
[22:16] <mok0> kumy: I will comment now on revu now. At the moment, I am on my mac laptop and can't check the application and installation. I will look at that later, but there are some things for you to do...
[22:17] <joaopinto> hum I have removed the .xpm now, should it be provided ?
[22:17] <joaopinto> isn't the .svg sufficient ?
[22:18] <kumy> mok0: ok, for the daemon to work properly you should have a frog device!
[22:21] <joaopinto> iulian, about the .xpm ...
[22:23] <iulian> joaopinto: I'm not sure if the .svgs are the right format to use. I suggest you to keep the .xpm icon and install it in /usr/share/pixmaps.
[22:24] <joaopinto> iulian, I noted now that the intial review asked me to not use the pixmap
[22:24] <mok0> kumy: yes I should!
[22:26] <joaopinto> I am going to leave the .xpm out, just to have a shorter diff :P
[22:26] <iulian> joaopinto: Right, I saw that comment. If norsetto said to use the .svg one, use it.
[22:27] <joaopinto> fixes applied, testing rebuild, and reuploading
[22:27] <iulian> My knowledge about icons are a bit rusty.
[22:27] <kumy> mok0: thaks for your revu. I'll work on it.
[22:27] <joaopinto> I hope the first package provides me some motivation for more :P
[22:32] <iulian> I should really go to bed now.
[22:32] <iulian> G'night.
[22:32] <joaopinto> handschuh, https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages states "* Initial Ubuntu package (LP: #242910)"
[22:33] <joaopinto> handschuh, who is correct :P ?
[22:34] <joaopinto> handschuh, what do you mean by hints to the files ? I do provide the author names on debian/copyright
[22:35] <handschuh> joaopinto:well ... all the packages I have looked at are writing "Initial release" which fits better, I think
[22:35] <handschuh> joaopinto: look at the format ... it is not correct
[22:35] <joaopinto> url please
[22:37] <handschuh> joaopinto: https://wiki.ubuntu.com/PackagingGuide/Basic
[22:38] <handschuh> joaopinto: at section copyright
[22:41] <joaopinto> handschuh, I don't have the names/emails for each author, and that example on the guide does not mention how list the copyrigh for different files
[22:42] <handschuh> joaopinto: yes, just don't divide - simply add them all without division into files
[22:42] <joaopinto> handschuh, if I don't add the filenames, how is the read to expect for which components does the license applies to ?
[22:42] <joaopinto> the reader
[22:43] <joaopinto> erm, how is the reader expected to know
[22:43] <handschuh> joaopinto: if you have different licenses in one project, you have to divide the projects (imho)
[22:44] <joaopinto> handschuh, uh ? as long as licenses are compatible why do I need to do that ? That is very common among open source software
[22:44] <jdong> that's not true, handschuh
[22:44] <jdong> the situation is quite tricky when a package is governed by several different licenses that are hard to figure out which applies to which, and who holds the copyrights, etc.
[22:45] <handschuh> jdong: no? well anyways, thats not what joaopinto mentioned
[22:45] <jdong> I ran into this problem dealing with debian/copyright on mpeg4ip
[22:45] <joaopinto> I really don't see the point of adding copyright owners on a big list, without a clear description for which file does the copyright applies to
[22:46] <jdong> joaopinto: see the debian/copyright in mpeg4ip and see if that provides a useful example
[22:46] <joaopinto> I mean, when you have a major part copyrighed from one party, and 1 or 2 files copyrighted by another party
[22:46] <jdong> it's (!) 363 lines long
[22:46] <handschuh> joaopinto: you do deliver the source ... if someone is interested in it, they just look at the source
[22:46] <jdong> and I had the package rejected twice by archive admins before being approved.
[22:47] <handschuh> jdong: sounds messy  :-/
[22:47] <jdong> so, AFAIK, it is the correct method of handling multiple-copyright aggregate works.
[22:47] <joaopinto> mpeg4ip does contain sections per components
[22:48] <joaopinto> I do the same, but for only 3 files
[22:49] <jdong> that sounds like the correct thing to do, to me.
[22:49] <jdong> but IANAL nor am I an archive admin, nor do I pretend to know much about how debian/copyright works other than from personal experience.
[22:51] <handschuh> joaopinto, jdong: lets wait and see if it gets aprooved ... (I really want to know if this is a policy)
[22:52] <joaopinto> I have added the Upstream section, but will leave the files copyright
[22:53] <handschuh> joaopinto: if you get advocate, please ping me (i have some packages with the same copyrightissue ... and i just wanted to add the authors to global copyright)
[22:54] <joaopinto> I will
[22:54] <handschuh> is there any official page about 2 license in one package?
[22:54] <handschuh> joaopinto: thanks
[22:54] <handschuh> s/license/licenses
[22:56] <joaopinto> I hate license handling :\
[22:57] <handschuh> joaopinto: with one license, it is easy but with 2 or even more ....
[22:57] <jdong> joaopinto: yeah we all hate it to some extent but it's something that has to be done
[22:57] <joaopinto> I hope I have the stomach for it with lives, since it reuses some libs/code
[22:57] <joaopinto> jdong, actually I would prefer it done by law people, not by developers :P
[22:57] <jdong> joaopinto: haha well said people are hard to come by :)
[22:58] <joaopinto> I know, we are cheaper :P
[22:58] <jdong> and blindly distributing software without attention to the licensing details sure won't lead anyone down a good road :)
[23:00] <joaopinto> most people do not care about such licensing details, so it is more from an enterprise/comercial perspective
[23:00] <joaopinto> not even copyright owners care about it, unless it damages it somehow
[23:05] <joaopinto> time to sleep
[23:06] <binarymutant> if anyone has any time to review my package, http://revu.ubuntuwire.com/details.py?package=charm, I would appreciate it very much. Thanks :)
[23:09] <joaopinto> http://revu.ubuntuwire.com/details.py?upid=4044 <- new upload <- Please advocate
[23:09] <joaopinto> we look spammers :D
[23:10] <joaopinto> hum, I was supposed to be sleeping
[23:13] <binarymutant> not part of the Eastern Standard Tribe I take it?
[23:14] <Hobbsee> binarymutant: er, i'd say you're confused here
[23:14] <Hobbsee> +   Note: This should happen automatically when you run
[23:14] <Hobbsee> +   dpkg-source -x on a dpatch source package.
[23:14] <Hobbsee> + * To generate the fully patched source, in a form ready for
[23:14] <Hobbsee> +   editing, that would be built to create Debian packages, run:
[23:14] <Hobbsee> +
[23:14] <Hobbsee> +     dpatch apply-all
[23:14] <Hobbsee> (other way around)
[23:14] <Hobbsee> dpkg-source -x applies the .diff.gz to the tarball and such - doesn't do anything with debian/patches/
[23:16] <Hobbsee> unless dpatch does something very whacky and non-standard?
[23:16] <Hobbsee> + * To remove source modifications that are currently being
[23:16] <Hobbsee> +   applied when building the package, run:
[23:16] <Hobbsee> ^ that's not true either, iirc.
[23:17] <Hobbsee> dpatch doesn't run dh_clean, and clean any temporary files and such - it only reverses the patches that have been applied previously
[23:17] <mok0> Is it possible to send a message to this channel from a local script?
[23:17] <Hobbsee> mok0: errr, depends how you do it
[23:18] <Hobbsee> mok0: if you connect an irssi instance, and run the script thru that, yes.
[23:21] <Hobbsee> binarymutant: review posted :)
[23:22] <binarymutant> thanks Hobbsee, I am very confused about dpatch
[23:23] <Hobbsee> binarymutant: dpatch *only* takes the stuff from debian/patches, and does stuff with it
[23:23] <Hobbsee> either applying it, or removing it
[23:23] <Hobbsee> binarymutant: how are you confused by it?
[23:23] <pochu> what was that command to make big letters with ascii symbols?
[23:23] <directhex> pochu, figlet
[23:23] <directhex> pochu, or the superior alternative: toilet
[23:24] <mok0> pochu: or banner
[23:24] <pochu> wow, thanks!
[23:24] <directhex> because the archive needs three different ways to make the word "dongs" huge for posting on irc
[23:24] <directhex> other useful packages to consider include "sl"
[23:25] <directhex> which is unrelated, but just as useful
[23:25] <mok0> directhex: of course, there is also the utility "vi"
[23:25] <directhex> mok0, vi also belongs in the "worthless" category ;)
[23:26]  * Hobbsee thought a 00list was mandatory for dpatch, if you wanted patches to actually get applied.
[23:26] <mok0> directhex: ah, another "nano" fanboy
[23:26] <directhex> Hobbsee, so did i
[23:26] <directhex> mok0, o_o my secret is revealed?
[23:26] <mok0> Hobbsee: isn't it?
[23:27] <binarymutant> Hobbsee, I'm confused at what you mean in the review, I have 00list, are you saying my rules file is wrong? Because I did have trouble with that
[23:27] <Hobbsee> mok0: i'm not sure.  I'm fairly certain that it is.
[23:28] <Hobbsee> binarymutant: no, not yours - that was joaopinto's :)
[23:28] <Hobbsee> mok0: i know i've got caught before with other types of patch systems for that.
[23:28] <mok0> Hobbsee: I think so too... if 00list is not there, nothing will be done
[23:28] <Hobbsee> yeah
[23:29] <directhex> and lintian will beat you with a stick
[23:29] <Hobbsee> lintian hasn't mentioned it
[23:29] <mok0> ouch
[23:29] <mok0> sounds nasty
[23:29]  * Hobbsee gets out the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™
[23:29]  * Hobbsee tickles mok0 with it
[23:29] <mok0> oh noes
[23:29] <Hobbsee> Right.  Done two reviews today now.  \o/
[23:30] <binarymutant> Hobbsee, o sorry, but still confused on the review. My rules are not right? because it applies the patch when being built and when cleaning the package it deapplies it...
[23:30] <mok0> Hobbsee: ... now if only all MOTUs would do that...
[23:30] <mok0> binarymutant: sounds right
[23:30] <Hobbsee> binarymutant: no, your rules are right.  It's just your documentation at README.source is wrong.
[23:31] <mok0> binarymutant: when you get dpatch to work, go learn about dpatch-edit-patch.... soooo cool
[23:31] <Hobbsee> +   Note: This should happen automatically when you run
[23:31] <Hobbsee> +   dpkg-source -x on a dpatch source package.
[23:32] <Hobbsee> ^ binarymutant you can get rid of those lines completely - because a) they're wrong, and b) whoever reading it will have already done that step anyway, so doesn't need the documentation on it
[23:32] <Hobbsee> + * To remove source modifications that are currently being
[23:32] <Hobbsee> +   applied when building the package, run:
[23:33] <Hobbsee> and for that, i'd suggest changing it to something like "To undo patches that have been previously applied to the source package, run:"
[23:33] <Hobbsee> binarymutant: if you build in pbuilder, it will automatically add and remove patches for you (assuming you've done it right)
[23:34] <Hobbsee> so you don't really need to worry
[23:36] <binarymutant> Hobbsee, Oh okay, I just copied the the readme.source entirely. I'll edit it.
[23:37] <binarymutant> why doesn't dpkg-source -x apply my patches though? shouldn't it?
[23:37] <Hobbsee> binarymutant: oh, where'd you copy it from?
[23:37] <binarymutant> Hobbsee, debian policy I think
[23:38] <mok0> binarymutant: patches are applied when you build the binary
[23:39] <mok0> binarymutant: ... not when running dpkg-source -x, that only unpacks the source package
[23:39] <binarymutant> mok0, I know, but shouldn't dpkg-source -x apply it as well? or no
[23:39] <mok0> binarymutant: no
[23:39] <Hobbsee> binarymutant: no, that only unpacks the source. it does nothing to the binary.
[23:39] <Hobbsee> binarymutant: if it did, you'd find it kinda difficult to get the unpatched source.
[23:40] <Hobbsee> binarymutant: the way it works is this:
[23:40] <binarymutant> oh okay, thanks for the review Hobbsee :)
[23:40] <directhex> dpkg-source just untars your orig.tar.gz, and then applies your diff.gz to it - diff.gz contains your debian/patches, but doesn't apply those patches itself
[23:40] <binarymutant> I need to find where I got that readme.source
[23:41] <Hobbsee> you get bits of source, you unpack that source, you make any changes you want to, you tell it to build in pbuilder.  The building then applies the patches, builds the package, then removes the patches again, so you get back to a pristine source.
[23:43] <binarymutant> I was confused by this http://wiki.debian.org/debian/patches, under proposed improvements it says dpkg-source should apply patches
[23:43] <binarymutant> I guess it's still being proposed
[23:43] <crimsun> superm1: yes, per-codec table.
[23:44] <superm1> crimsun, could there be more granularity to it though to allow for platforms that share codecs, at least until proper support to read EQ values from the BIOS are in ALSA?
[23:45] <mok0> binarymutant: ah, yes that is only proposed.
[23:45] <azeem> I think it's implemented as well, but should not be used yet
[23:45] <mok0> binarymutant: It would eliminate certain problems if dpkg-source applied patches, but it doesn't now
[23:46] <mok0> azeem: it's implemented?
[23:46] <binarymutant> ok I'll edit that out of my readme.source, thanks everyone for the help and thanks Hobbsee for the review
[23:46] <Hobbsee> binarymutant: you're welcome
[23:46] <mok0> :-)
[23:47] <azeem> mok0: AIUI, recent versions of dpkg-source can unpack those new source package formats - not sure whether anything can generate them yet
[23:48] <crimsun> superm1: how much more granularity do you need beyond per-codec?
[23:48] <directhex> iirc everything supports the new source formats except the debian archive, e.g. dak
[23:48] <mok0> azeem: There is also a lot of talk about using VCSes for patch management,
[23:49] <mok0> patch & package
[23:49] <superm1> crimsun, well perhaps if you can go off of HAL output of the platform if the information is provided, otherwise use the stored default codec information
[23:49] <superm1> crimsun, say maybe using system.hardware.product and system.hardware.vendor
[23:50] <binarymutant> should https://wiki.edubuntu.org/README.sourceHowTo be changed to reflect that dpkg-source -x doesn't apply patches? I think I remember seeing these on a debian site as well
[23:52] <superm1> crimsun, if nothing else it's planning ahead.  i know that until EQ support is in, good default values on at least two laptops sharing a common codec aren't the same and cause resonance on the chassis
[23:53] <crimsun> superm1: same revisions of the same codec?
[23:53] <superm1> crimsun, yes
[23:55] <crimsun> superm1: right, it's just a minor step.  I presume you're referring to the STAC9*, because I know at least ALC88[23] have the same problem.
[23:56] <superm1> crimsun, yes
[23:56] <crimsun> I find that we need at least SSID and codec (and its revision)
[23:57] <mok0> binarymutant: let's check it out in details
[23:57] <superm1> crimsun, at least in the cases i've seen, the hardware was developed simultaneously, with a few enhancements to the chassis for some other hardware that landed in it.  consequently they had a lot of similar or even identical components, but ended up with different values that got read from the BIOS in the windows driver for setting up the EQ in vista.
[23:58] <binarymutant> mok0, k
[23:59] <directhex> sniff sniff, do i smell software pin assignments?
[23:59] <directhex> i still have slightly odd sound behaviour on my imac in the office