[00:07] <nealmcb> NCommander, ng, nxvl: I just noticed that while pushing bzr --fixes doesn't change the bug, it does provide a little button on the trunk page to update the bug.  I see it, and hope others do also:  https://code.edge.launchpad.net/~nealmcb/electionaudits/trunk
[00:07] <NCommander> oh
[00:07] <wgrant> nealmcb: The link will also appear on the bug page.
[00:08] <wgrant> --fixes shouldn't close the bug, because the branch might not be merged into trunk yet.
[00:08] <nealmcb> wgrant: ah - yes indeed - interesting
[00:08] <RAOF> Although there's discussion about making that happen when it _is_ merged to trunk.
[00:09] <wgrant> RAOF: Indeed, that would be good.
[00:09] <nealmcb> I wish the doc was clearer about all that. and I did see the conversation https://bugs.edge.launchpad.net/bzr/+bug/120050
[00:09] <ScottK-laptop> I disagree.
[00:09] <wgrant> Merging stuff is changing, so it's not unthinkable.
[00:09] <wgrant> ScottK-laptop: On which point?
[00:09] <ScottK-laptop> It shouldn't get marked fixed until it's in the archive.
[00:09] <wgrant> ScottK-laptop: I think we're talking about upstream tasks.
[00:09] <RAOF> ScottK-laptop: I think we're talking about different things.
[00:09] <ScottK-laptop> Ah.
[00:09] <wgrant> Distros don't have branches (yet).
[00:09] <ScottK-laptop> Ah.
[00:09] <ScottK-laptop> Nevermind then.
[00:10] <RAOF> And when distros _have_ branches, then I'd suggest that "fix committed" is a worthwhile status for "fix in trunk, but not yet in archive" :)
[00:10] <wgrant> But actually, you have a point - when something is merged to trunk, it should be marked Fix Committed, not Fix Released.
[00:11] <RAOF> I obviously missed the start of this conversation.  I thought that was the expected status!
[00:11] <wgrant> I guess I was thinking like changelog-closes-bugs.
[00:11] <ScottK-laptop> Which is fine for after it's actually released somewhere.
[00:11] <nealmcb> it offers fix-available for trunk now
[00:12] <nealmcb> for non-ubuntu projects (which is where I started this conversation)
[00:13] <cosmodad> hi all. I'm doing my first backport since I've upgraded to hardy, when when I do a dpkg --compare-versions of 1.2ubuntu3~hardy1 against 1.2ubuntu3, first isn't anymore greater-or-equal than latter. Has something changed on the version policy?
[00:13] <cosmodad> s/when/but/
[00:14] <wgrant> cosmodad: ~ is explicitly less than nothing.
[00:14] <RAOF> cosmodad: That's the expected behaviour; ~ always sorts after everything else
[00:14] <NCommander> cosmodad, that's be design
[00:15] <cosmodad> wow. :)
[00:15] <cosmodad> hmm I could swear this has worked before.
[00:15] <wgrant> Not a chance.
[00:15] <NCommander> Backports, and SRUs require the ~ to make sure upgrades work sanely
[00:15] <wgrant> NCommander: Not SRUs.
[00:16] <NCommander> Oh right
[00:16] <NCommander> SRU's use X.1
[00:16] <NCommander> ANd so forth
[00:16] <wgrant> No, that's -security.
[00:16] <cosmodad> ok so I get this error: "ifupdown depends on netbase (>= 4.30ubuntu2); however: Version of netbase on system is 4.30ubuntu2~hardy1." How'd I resolve it properly?
[00:16] <wgrant> SRUs use whatever the uploader wants, which is bad.
[00:16] <wgrant> cosmodad: Find the ifupdown dep.
[00:16] <nealmcb> hmm - but just clicking on "fix available" on one of those pages and hitting "update" doesn't do anything.  and putting a comment in the box adds a comment but doesn't change the status
[00:16] <wgrant> Er, Fix.
[00:16] <NCommander> wgrant, wait .... seriously? I thought SRU was standardized on the version it used
[00:17] <NCommander> wgrant, and security isn't always standardized. There are some oddball exceptions
[00:17] <wgrant> NCommander: No - that would make sense.
[00:17] <directhex> yay, NCommander is here
[00:17] <cosmodad> wgrant: well I backported netbase myself, so what do I need to fix? how to version the package?
[00:17]  * NCommander notes that backporting a base package like netbase is a bad idea
[00:17] <wgrant> NCommander: Security is always X.1, unless the same version is in different distroseries, in which case it's X.Y.MM.Z
[00:17] <wgrant> (Y.MM being the distroseries version number)
[00:17] <NCommander> wgrant, clamav using backport versioning
[00:18] <NCommander> wgrant, mostly because that's what clamav uses for security
[00:18] <NCommander> or something to that effect
[00:18]  * NCommander notes clamav sucks but yeah
[00:18] <cosmodad> NCommander: I know, but it's just one debian revision number which I require.
[00:18] <NCommander> cosmodad, your asking to break your system
[00:19] <NCommander> anyway, to resolve your issue
[00:19] <NCommander> You must backport every rdepend that has binary:Version depends
[00:20] <NCommander> (beside the obvious chance of regressions, this is why we try to avoid backporting packages with rdepends out the wazoo)
[00:23] <wgrant> NCommander: True, ClamAV is a very special case.
[00:23] <wgrant> Like Firefox.
[00:24] <cosmodad> NCommander: I backported both ifupdown and netbase. They depend on each other, and no other rdepend is affected as the other's rdepends are ok with respect to version numbers.
[00:24] <cosmodad> NCommander: so I don't see what I'm missing.
[00:25] <NCommander> cosmodad, you need to edit the control files to also make sure all the version numbers match
[00:25] <NCommander> I emphasize again that this is a horribly stupid idea if you care about your computer
[00:26] <cosmodad> NCommander: on numerous backports I've done before, I never touched the version fields of debian/control. How come it is required now?
[00:26] <cosmodad> is it because of the circular dependency?
[00:27] <NCommander> Because there are likely hardcoded version numbers for a reason
[00:27] <cosmodad> hard-coded in control you mean?
[00:27] <NCommander> yeah
[00:27] <NCommander> I'm going to be blunt. Unless you explain why you need netbase on hardy and can't upgrade to intrepid, I don't think I can help you anymore; what your trying to do is absolutely crazy.
[00:28] <cosmodad> NCommander: intrepid is still beta, and the versions of ifupdown and netbase I require fix a bug that makes my wifi work when starting up my machine and possibly also when I recover from STR/D.
[00:29] <cosmodad> NCommander: I'll reconsider doing what I do if you'd be so kind and re-explain to me why this is so crazy.
[00:29] <cosmodad> I still don't see the point as this is just a minor change.
[00:29]  * NCommander bashes his head into a wall a few times
[00:31] <cosmodad> just for the sake of knowledge, please explain.
[00:31] <NCommander> netbase controls ipup/ipdown/etc. Looking at the changelog, those commands had some internal changes to the way they handle networking, and in addition, should there be a incompability, you are promised to break your machine
[00:32] <NCommander> If you break your machine
[00:32] <NCommander> No one will be able to help you, and you will be SOL
[00:34] <cosmodad> I see. And why couldn't a simple reinstall of the old versions fix such a problem?
[00:36] <nealmcb> wgrant: I'm also surprised that although launchpad updates the bug page about the fix in the branch, it doesn't send mail about that.  Anyway, this discussion should go on in #launchpad, but I just had wanted to track down those situations in ubuntu where this stuff does work, based on queries raised in #launchpad.  thanks, all!
[00:37] <wgrant> nealmcb: Hmmm, that lack of mail sounds like a bug.
[00:39] <zul> geser: yes I can do it tomorrow
[00:41] <directhex> what am i doing wrong if i get "dh_installchangelogs: I have no package to build"
[00:43] <RAOF> directhex: Trying to build arch-all packages on !i386?
[00:44] <directhex> RAOF, isn't that an ubuntu issue, not one you meet when using dpkg-buildpackage ?
[00:45] <RAOF> Possibly.  Although you could get it by running a build with the smart arch-all flag (-a ?) locally, I think.
[00:52] <directhex> it's arch:any
[00:52] <directhex> but now you mention it, the -dev package ought to be all
[00:59] <directhex> RAOF, somehow you're right - the arch:all package builds fine, the arch-any packages are ignored
[00:59] <nealmcb> wgrant: I added comment about lack of --fixes mail to that bug I noted before.  thanks again
[01:03] <ScottK-laptop> NCommander: Clamav had backports revision numbers in -updates and -security because it lived in backports for a while and then got copied over once it was well tested.
[01:04] <NCommander> ScottK, sounds like loads of fun ;-)
[01:04] <ScottK-laptop> It was.
[01:05] <ScottK-laptop> OTOH, getting the same clamav version in 4 releases with all the rdepends working was kind of my thesis project for my core-dev application.
[01:06] <ScottK-laptop> Just to pick one particularly 'fun' example, if you look at avscan in Dapper you'll find the -updates version is the Dapper Debian packaging, the Feisty base package, and one file grabbed from the Hardy version.
[01:07] <NCommander> o_o;
[01:08] <NCommander> ScottK, you need to look at the subversion backport
[01:08] <NCommander> It got tested
[01:09] <ScottK-laptop> NCommander: OK.  I like sticking with openssl.
[01:09] <ScottK-laptop> Since that's what Hardy already does.
[01:09] <ScottK-laptop> How do you feel about that?
[01:10] <NCommander> Works for me since its the path of least resistance so to speak
[01:10] <NCommander> ScottK, it also lets me backport 1.5.2 once I find some piece of mind.
[01:10] <ScottK-laptop> OK.  Is there a debdiff for that in the bug?
[01:10] <NCommander> ScottK, should be
[01:11] <ScottK-laptop> K.  What's the bug number again?
[01:11] <NCommander> ScottK, also look at this one https://bugs.edge.launchpad.net/hardy-backports/+bug/276016
[01:12] <NCommander> Hrm
[01:12] <ScottK-laptop> We aren't ready on that one yet.  We need work on the rdepends.
[01:12] <ScottK-laptop> Need to figure out what to do about avscan.
[01:12] <NCommander> https://bugs.edge.launchpad.net/hardy-backports/+bug/265065
[01:14] <NCommander> ScottK, also https://bugs.edge.launchpad.net/hardy-backports/+bug/243583
[01:15] <NCommander> ScottK, https://bugs.edge.launchpad.net/hardy-backports/+bug/241560
[01:15] <NCommander> :-)
[01:16] <ScottK-laptop> NCommander: I've stared at that one a bit, but not with enough alcohol in my bloodstream to actually come op with a solution (243583)
[01:16] <NCommander> I posted a solution
[01:16] <NCommander> A backport of webkit fixes it
[01:17] <NCommander> or at least it did
[01:17] <NCommander> THat being said, libqtwebkit was removed from intrepid -_-;
[01:18] <NCommander> It's qt4-webkit now
[01:18] <ScottK-laptop> Right.  You don't want libqtwebkit
[01:18]  * ScottK-laptop goes to help the 5 year old clean the kitchen
[01:20] <NCommander> ScottK, https://bugs.edge.launchpad.net/hardy-backports/+bug/257211 also
[01:25] <NCommander> ScottK, also https://bugs.edge.launchpad.net/hardy-backports/+bug/260998
[01:41] <csilk> What exactly is a lintian out fo date standards warning?
[01:42] <wgrant> csilk: A warning from lintian that the package asserts compliance to an old Standards-Version.
[01:42] <csilk> How can I rectify this?
[01:42] <ScottK-laptop> Generally you don't.
[01:43] <wgrant> csilk: Ensure that the package complies with the newest version of Debian policy, and update the version number in debian/control.
[01:43] <ScottK-laptop> wgrant: Unless we're getting the package from Debian, then you don't
[01:44] <wgrant> ScottK-laptop: Good point. But I would have thought it should be well known that you only make minimal changes in Debian-derived packages.
[01:44] <csilk> wgrant, as far as I'm aware the package meets the latest debian policy. I'll just ammend the Standards-version: fiel din control, i assume that iwll remove the warning
[01:44] <wgrant> csilk: As ScottK says, you would only do that if it was not in Debian.
[01:44] <ScottK-laptop> wgrant: Right, well Ubuntu Policy specifically says not to change it now.
[01:45] <wgrant> And you can't say "as far as I'm aware"; you need to check.
[01:45] <wgrant> ScottK-laptop: Oh, good.
[01:47] <emh> what is the difference between Depends and PreDepends in a ubuntu package?
[01:48] <ScottK-laptop> Same as in Debian.
 csilk: As ScottK says, you would only do that if it was not in Debian.
[01:48] <csilk> wgrant,  it's not in debian
[01:49] <wgrant> csilk: Ah, OK. Probably best to only make minimal changes at this point in the cycle, however.
[01:49] <csilk> fyi, this is the first package I've ever done in preperation for revu
[01:50] <wgrant> How did you get the old standards-version in the first place if it's a new package?
[01:50] <csilk> I have no idea, That's what dhmake did for me
[01:55] <csilk> wgrant,  any idea why dh_make would do that?
[01:56] <wgrant> csilk: Because it's old, probably.
[01:57] <csilk> wgrant,  the version of dh_make I'm using is the latest availabel via apt-get install
[01:57] <csilk> *available
[01:57] <csilk> unless of course that is a minor version out of date
[01:57] <csilk> either way, i changed it to the latest version considering this is a new package
[01:58] <ScottK-laptop> Well if you're using the Hardy version you're getting what was current when Hardy was released.
[02:00] <csilk> I'll be testing this in a chroot intrepid
[02:03] <csilk> Brilliant, lintain returns no errors and no warnings after I fixed the distclean option :D
[02:03] <csilk> *lintian
[02:04] <ScottK-laptop> csilk: Look in hardy-backports for a newer version.
[02:06] <csilk> will do
[02:18] <ryanakca> monopd suggests a package not included in Intrepid (atlantik)... who would I forward a debdiff to to have it uploaded?
[02:20] <ScottK-laptop> ryanakca: atlantik was part of kdegames in KDE3, but not ported to KDE4.
[02:20] <ScottK-laptop> So it's gone.
[02:20] <ryanakca> ScottK-laptop: no, to have the suggests removed?
[02:20] <ScottK-laptop> Ah.
[02:21] <ScottK-laptop> ryanakca: I'll take care of it.
[02:21] <ryanakca> ScottK-laptop: http://ryanak.ca/~ryan/monopd_0.9.3-4ubuntu1.debdiff
[02:23] <ScottK-laptop> ryanakca: You forgot the maintainer change.  I got it.
[02:24] <ryanakca> ScottK-laptop: splendid, thanks :)
[02:25] <NCommander> hey ScottK
[02:27] <ScottK-laptop> Heya NCommander.
[02:27] <ScottK-laptop> Subversion is still building.
[02:27] <NCommander> \o\
[02:27] <NCommander> There were a bunch of other backports I asked you to look at ;-)
[02:28] <ScottK-laptop> Yeah.  Subversion was the one I agreed to look at.
[02:29] <NCommander> -_-;;;;;;;;;;;;;;
[02:29] <ScottK-laptop> I'll do the qt webkit one too.  What's the bug number?
[02:29] <NCommander> ScottK, sudo look at backports
[02:29] <NCommander> :-)
[02:29]  * ScottK-laptop is on break.  jdong is Mr. Backports this fall.
[02:29] <NCommander> ScottK-laptop, jdong hasn't been active it seems
[02:30] <NCommander> ScottK, there a lot that have no need for uploads, just need an ACK
[02:30] <NCommander> https://bugs.edge.launchpad.net/hardy-backports/+bug/243583
[02:30]  * ScottK-laptop smacks jdong in the head to get his attention.
[02:31] <ScottK-laptop> Right.  I'd really rather he did those.
[02:31] <NCommander> Some of them are almost a month old
[02:31] <NCommander> And since I'm not a backporter, I can't actually approve them -_-;
[02:32] <ScottK-laptop> NCommander: What exactly am I approving on that one?
[02:32] <nxvl> nellery: hi!
[02:33] <NCommander> the webkit backport, but I'm still not 100% its the right fix, I wanted someone else to perform a sanity check on it to make sure I didn't misanything
[02:33] <ScottK-laptop> I don't have the spare cycles to really consider it, nor do I have a hardy machine to test it on.
[02:34] <NCommander> I'll reconfirmed that backporting webkit makes things installable, but webkit has a rather nasty set of rdepends
[02:34] <NCommander> It might break things worse
[02:34] <ScottK-laptop> ryanakca: Uploaded.  Thank you for your contribution to Ubuntu.
[02:35] <NCommander> *reconfirm
[02:35] <ScottK-laptop> Which would have to be tested
[02:35] <NCommander> right
[02:36] <NCommander> But the broken dev package also breaks loads of things
[02:36] <NCommander> (Qt's development headers are uninstallable ATM)
[02:37] <ScottK-laptop> Right and in Kubuntu webkit wasn't really used for anything in Hardy, so it's safe.  I'm worried about Gnome though.
[02:37] <NCommander> some of would consider a broken GNOME a feature ;-)
[02:37]  * NCommander runs
[02:38] <NCommander> We could probably hack the **** out of libqtwebkit to work, but thats also asking for a nice headache when upgrade time comes
[02:39] <ScottK-laptop> Yep.
[02:40] <ScottK-laptop> NCommander: Wouldn't adding a conflicts/replaces in libqt4-dev on libqtwebkit-dev solve it?
[02:40] <NCommander> Hrm ... maybe
[02:40] <ScottK-laptop> We probably want that for upgrades anyway in Intrepid
[02:40] <NCommander> As far as installability goes
[02:41] <ScottK-laptop> I think the issue is that the QT webkit stuff got folded into the main QT4 packages and not split out.
[02:41] <NCommander> Maybe we should simply backport the current Qt package, and then leave a virtual libqtwebkit one in its place
[02:41] <NCommander> Probably less likely to hose things then mucking around new Qt + old webkit
[02:43] <ScottK-laptop> I don't think we want to take the hardy-backports QT4 from 4.4.0 to 4.4.3
[02:43] <NCommander> Well, wasn't upgrading Qt in the first place what broke everything so miserably?
[02:45] <ScottK-laptop> To 4.4.0.  Let's not build on the problem.
[02:45] <NCommander> Point taken
[02:45] <NCommander> I think the problem is the new Qt has the development headers of libqtwebkit
[02:45] <ScottK-laptop> 4.4.3 has the conflicts already, so I'll just add it to the hardy-backports one.
[02:45] <ScottK-laptop> Yes.
[02:45] <NCommander> We still have the problem that anything that depends on lib-qtwebkit will go boom
[02:46] <ScottK-laptop> So it has to conflict/replace it.
[02:46] <NCommander> We need a virtual package so we don't break anything that depends on libqtwebkit-dev
[02:46] <ScottK-laptop> Does anything?
[02:46] <ScottK-laptop> IIRC it was pretty much a late afterthought that was almost immediately regretted.
[02:46] <NCommander> Checking
[02:47] <NCommander> what was
[02:47] <NCommander> libqtwebkit-dev?
[02:47] <ScottK-laptop> Yes.
[02:47] <ScottK-laptop> And libqtwebkit
[02:47] <NCommander> (I know we have two backports stalled because its uninstallable)
[02:47] <NCommander> Well, libqtwebkit is file
[02:47] <NCommander> *fine
[02:48] <NCommander> If we scratch the source package via a removal, the dev package would disappear, but NBS would prevent the library from going poof
[02:48]  * NCommander feels his hack meter go off
[02:49] <NCommander> apt-cache rdepends says that only libqt has a depends on libqtwebkit
[02:49] <ScottK-laptop> Which isn't a problem if you have the new QT4.
[02:50] <NCommander> so its just a matter of turning libqtwebkit into a transitional package so anything that build-deps on it still works sanely if you have backports enabled
[02:50] <ScottK-laptop> No NBS because we aren't touching the release pocket.  Only backports.
[02:50] <ScottK-laptop> The we just add provides to the mix then.
[02:50] <ScottK-laptop> The/Then
[02:51] <NCommander> We have a versioned depends
[02:51] <NCommander> a provides won't do the trick
[02:51] <ScottK-laptop> Where?
[02:52] <ScottK-laptop> Back in 5
[02:53] <jdong> sigh, jdong is being raped by Ron Rivest's homework assignment this weekend; please give me another 5 hours or so to be alive.
[02:53] <jdong> (yes that's the R in RSA)
[02:55] <csilk> Would i tbe benefical to update my version of pbuilder if building a package fro intrepid?
[02:55] <csilk> *for
[02:57] <ScottK-laptop> Yes.  That's also in hardy-backports
[02:58] <csilk> i'd of thought so, although i cant find it in hardy backports
[02:58] <ScottK-laptop> Ah.  Actually it's the new debchroot that you want.
[02:58] <ScottK-laptop> Not pbuilder
[02:59] <ScottK-laptop> NCommander: Where's this versioned depends?
[02:59] <NCommander> I thought libqt-dev has a versioned depends on libqtwebkit-dev
[02:59] <NCommander> So I guess the problem is mute now that I thought about it
[02:59] <ScottK-laptop> mute/moot, but yes.
[03:00] <ScottK-laptop> NCommander: Why don't you whip me up a debdiff for that then?
[03:00] <csilk> debchroot?
[03:01] <ScottK-laptop> That (or something very close to that) is what pbuilder uses to make the chroot it builds inside of.
[03:02] <csilk> rite, so I'd need to update my version of that package
[03:03] <csilk> i cant find anything even similar to it in hardy-backports
[03:07] <ScottK-laptop> NCommander: Didn't we want to add something openssl'ish to the build-dep for subversion?
[03:09] <NCommander> ScottK-laptop, thats pulled in via the libneon build dep
[03:09] <ScottK-laptop> So it's OK I don't see openssl pulled in as a dep to any binary?
[03:10] <NCommander> Yeah, openssl -> libneon -> subversion
[03:10] <NCommander> SOmeone already confirmed the debdiff works
[03:10] <NCommander> (since I uploaded it to the PPA
[03:11] <ScottK> OK
[03:12] <ScottK> NCommander: Subversion uploaded.  Thank you for your contribution to Ubuntu.
[03:13] <cody-somerville> NCommander, don't be late
[03:14] <NCommander> On what?
[03:14] <NCommander> ^- cody-somerville
[03:18] <NCommander> cody-somerville, ?
[03:36] <ScottK-laptop> NCommander: Now he's got you worried.  That's a success for a manager.
[03:38] <NCommander> ScottK, not when his coworkers loose their mind and are committed
[03:38] <NCommander> ;-)
[03:38]  * NCommander bzr ci's himself
[03:42] <RickZilla> Ok, I'm officially in the market for a sound card that will work on my Pentium 4 ubuntu machine...taking any and all recommendations! Thanks for your help.
[03:42] <cody-somerville> RickZilla, I recommend anything off the shelve.
[03:44] <RickZilla> cody-somerville:  I spent about 6 hours trying to troubleshoot why I didn't have sound on my Creative Soundblaster card on my Dell machine...I'm just looking to see what other lInux users are having success with
[03:45] <cody-somerville> The 90's called, they want their soundcard back.
[03:47] <RickZilla> :-)
[03:47] <RickZilla> The machine itself is about 6 years old, so you're not too far off the mark.
[04:53] <csilk> If theres a package for an app already made but isn't available in the repo what policy dictates how it could make it's way to the repo, could i just check it's conformity then upload to revu or what?
[04:55] <ScottK> Yes, but with the understanding that we aren't taking new packages for Intrepid any more.
[04:56] <csilk> Yeah I know, I'd be waiting till after the release of intrepid of course
[05:05] <alteregoa> how can i manual select the gateway?
[08:06] <Hobbsee> Someone should package up the hardy wallpapers, and put them into intrepid.
[09:33] <Pupeno1> Hello.
[09:34] <Pupeno1> How do I get the version of the package inside rules?
[10:58] <sebner> asac aka nm-rocker \o/ ^^
[12:27] <james_w> directhex: hi, I'd like your opinion on a bug please
[12:27] <james_w> bug 211347
[12:27] <james_w> directhex: how hard would it be to make the list dynamic?
[12:33] <directhex> dynamic IWW?
[12:35] <directhex> oh, you mean stop forcing a size on the array, so it doesn't die when it finds too many foo or bar controllers?
[12:38] <directhex> oh lord, what dumb code.
[12:39] <directhex> james_w, busy with other tasks right now, but System.Collections.ArrayList is a dynamic-length array you can just add items to. hard-coded array sizes = moronic in extremis
[12:42] <directhex> OR, if you're looking for the "better" solution, look towards compiling the app against .net 2.0 using gmcs instead of 1.0 (we're dropping support for 1.0 apps in jaunty) - which adds generics, and you can use a string list generic
[12:44] <StevenK> directhex: C has hard coded array sizes?
[12:45] <sebner> StevenK: C#? yes
[12:45] <StevenK> No, C
[12:45] <directhex> StevenK, it's C# though. and it has a hard-coded size if you explicitly create a new array with 5 null objects in it
[12:46] <directhex> StevenK, using a smart language then chopping off a leg is dumb
[12:47] <StevenK> directhex: You may want a hard limit, though. It depends on the situation.
[12:49] <directhex> not in this one. this is a fairly old pc and exceeds some of this app's hard-coded limits by more than 2x
[12:49] <directhex> generally speaking, when is lspci output gonna need hard-coded limits?
[12:51] <StevenK> I dunno. The last program I wrote that touched lspci was written in Perl :-)
[12:54] <directhex> StevenK, it's pretty obvious the guy doesn't underdtand what he's doing anyway - to make a fixed size array, use String[n] not String[]={null,null,null,...,null}
[13:10] <james_w> thanks directhex
[13:16] <slytherin> geser: can you please ack bug #277088
[14:08]  * marnanel has a cdbs question.  I am packaging a GNOME application.  I added "include /usr/share/cdbs/1/class/gnome.mk" to debian/rules.  When it runs it attempts to run "configure" (which doesn't exist) rather than "autogen.sh".  I should package it in the post-autogen.sh'd state?
[14:08] <marnanel> s/runs/installs/ (and fails, obviously)
[14:12] <azeem> marnanel: yeah, or override the configure target
[14:13] <azeem> marnanel: but the former is probably better, unless this is a badly made upstream tarball you don't want to modify further
[14:13] <marnanel> azeem: okay, thanks.  just wanted to check before I did anything crazy.
[14:14] <azeem> marnanel: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml has some nice examples, but there is also a lot of crack in there
[14:14] <marnanel> thanks!
[14:14]  * marnanel is amused that cdbs is supposed to make everything easier and people immediately start talking about the crack in it :)
[14:15] <azeem> well, some intermediate maintainers of it added a lot of stuff which did crazy automatic stuff most people frowned upon
[14:15] <azeem> it got a pretty bad reputation in the Debian community by that time
[14:17] <azeem> also, the most important variable, DEB_CONFIGURE_EXTRA_FLAGS is only explained halfway through that document, after "automatic handling of debian/control" etc.
[14:23] <tobi> does "Please subscribe ubuntu-universe-sponsors to any bugs for which you wish to request sponsorship." mean I shall assign the bug via launchpad to ubuntu-universe-sponsors?
[14:23] <slytherin> tobi: which bug?
[14:25] <tobi> it's more a general question about the sponsoring process, the sentence above is from the ubuntu sponsor team page
[14:25] <slytherin> tobi: by the way, subscribe means subscribe, not assign
[15:20] <marnanel> Is it out of place to ask about packaging problems for PPA things?
[15:21] <james_w> marnanel: hey, if it's about the workings of PPAs the #launchpad is better, but for packaging things you can ask here
[15:22] <marnanel> Okay... I packaged something and it appears to have built, and I added my PPA to sources.list and did an update, and yet apt-cache search can't find it.  Is that anything obvious from the description?
[15:22] <marnanel> s/built/built properly/
[15:23] <james_w> marnanel: once it's built it will take a few minutes to be published, so if you were too quick you may have missed it
[15:24] <marnanel> Okay, thanks
[15:25] <james_w> marnanel: it's published now, so another update might work
[15:26] <marnanel> cheers
[15:26] <marnanel> YAY
[15:26] <marnanel> it's there
[15:26] <marnanel> thank you
[15:27] <james_w> no problem
[15:28] <directhex> directhex@mortos:/tmp/moon$ dpkg -l \*moon\* | grep ^ii
[15:28] <directhex> ii  libmoon-dev                                0.8.1+dfsg-1                                               open source implementation of Microsoft Silverlight
[15:28] <directhex> ii  libmoon0                                   0.8.1+dfsg-1                                               open source implementation of Microsoft Silverlight
[15:28] <directhex> ii  moonlight-plugin-core                      0.8.1+dfsg-1                                               open source implementation of Microsoft Silverlight
[15:28] <directhex> ii  moonlight-plugin-mozilla                   0.8.1+dfsg-1                                               open source implementation of Microsoft Silverlight
[15:40] <eagles051387> !pastebin | directhex
[15:42] <sebner> directhex: ahahaha
[15:42] <directhex> sebner, sat in SVN, awaiting tagging & uploading ;)
[15:43] <sebner> directhex: that's great but don't ignore the warning ^^
[15:46] <sebner> directhex: but why is it called moon?
[15:46] <directhex> sebner, dunno. blame upstream. the tarballs's called moon, and there's no moon source package, so...
[15:46]  * directhex moons sebner 
[15:46] <sebner> rofl
[15:46] <sebner> crazy
[15:48] <directhex> sebner, i'm sure there'll be petitions to remove it from the archive once it goes in, but still
[15:48] <sebner> directhex: really? I always thought people trust debian guys with license things and so on
[15:49] <directhex> sebner, TEH PATENTZ!
[15:49] <directhex> sebner, (ignoring the usual details)
[15:49] <directhex> sebner, funny thing is, moonlight DOES contain code (c) microsoft.
[15:49] <directhex> sebner, that code is licensed under Ms-PL
[15:50] <directhex> sebner, Ms-PL is a GPL3-compatible license containing a full patent grant
[15:52] <sebner> directhex: I know. funny :) ... Please remove moon from Debian Unstable. Rationale: PATENTZ :P
[15:52] <directhex> sebner, did you read http://www2.apebox.org/wordpress/linux/51/ ? ^_^
[15:53] <sebner> directhex: of course. I told you that that's  a great post :P
[15:54] <directhex> sebner, apologies, i have memory issues so i don't remember who has & hasn't seen something
[15:55] <sebner> directhex: np. :)
[15:55] <sebner> directhex: btw, I'm wondering if you also hack a little bit on smuxi!?
[16:02] <directhex> sebner, i have little time for app development
[16:03] <sebner> directhex: what a pitty, seems you have a good knowledge of C# :)
[16:03] <directhex> sebner, only what i've picked up, and applied from my java-based undergrad degree
[16:04] <sebner> directhex: oh my god. the j word xD
[16:04] <eagles051387> directhex: can you explain to me what the purpose of silverlight is. and 2ndly my degree is also java based lol
[16:04] <sebner> eagles051387: to kill flash :P
[16:05] <eagles051387> silverlight = flash equivalent
[16:05] <directhex> eagles051387, silverlight is largely a flash competititor. there are other distinctions, but the easiest description is "microsoft's version of flash"
[16:06] <directhex> iirc all the streaming access to the olympics in the US was done via silverlight
[16:06] <eagles051387> wow
[16:06] <eagles051387> someone needs to dev a linux based flash player to compete with adobe flash and silverlight
[16:07] <directhex> well, gnash is a cross-platform reverse-engineered flash player
[16:08] <eagles051387> the problem with that is it doesnt work in firefox
[16:08] <directhex> moonlight is a cross-platform implementation of silverlight
[16:08] <eagles051387> i had it and with ff3 it never used to work for me
[16:08] <eagles051387> ahhh gotcha that would be sweet to have in repos
[16:08] <sebner> eagles051387: it will, with jaunty ;)
[16:08] <eagles051387> ?
[16:08] <eagles051387> jaunty is next aprils release
[16:09] <directhex> right.
[16:09] <eagles051387> already have the name for it
[16:09] <directhex> sebner, depending on how meebey feels, i might publish a moon package into my mono repo today
[16:09] <directhex> sebner, i want approval on the package as-is first
[16:09] <eagles051387> well when i get settled down with my lecture schedule im going to start helping pkg stuff and bug fix if i can
[16:10] <sebner> directhex: nice, I think I have moonlight through a firefox xpi installed but never used it so far
[16:10] <directhex> eagles051387, http://www2.apebox.org/wordpress/wp-content/gallery/00-single/moonlight.png is a couple of embedded silverlight objects in a web page, running via moonlight
[16:11] <eagles051387> nice
[16:12] <eagles051387> !info moonlight
[17:11] <marnanel> I was asked to put up a trunk build of metacity in my PPA.  But of course that replaces metacity, metacity-common, etc.  I put "Replaces:" those in the debian/control file, but it doesn't replace them, and the line doesn't show in apt-cache show.
[17:12]  * marnanel asked in #launchpad and they sent me right back here :)
[17:12] <azeem> marnanel: "Replaces" simply indicates that this package overwrites files from the package it replaces
[17:12] <azeem> you need more magic to have APT actually install that package in favour of the other
[17:13] <azeem> marnanel: why did you rename the package, instead of just bumping the version?
[17:13] <azeem> it seems both are not parallel-installable anyway
[17:15] <marnanel> hm.  a) I knew they weren't parallel-installable: I wouldn't have expected to replace one with the other if they were, unless I'm confused.  b) all the other nightly trunk packages I've seen used different names.  I worried I'd tread on the real maintainer's toes
[17:15] <azeem> hrm, ok
[17:15] <azeem> marnanel: what's an example for another nightly trunk, or are those local packages?
[17:16] <marnanel> azeem: avant-window-navigator has awn-manager-trunk, python-awn-trunk, awn-extras-applets-trunk, and some others
[17:18] <gilir> marnanel: but we use Replaces: and Conflicts: field :)
[17:19] <azeem> marnanel: heh, and google is full of installation dependency issues with those :)
[17:21] <marnanel> Okay, so, what should I do instead?  "metacity"?  wouldn't that annoy the real Ubuntu maintainers for me to start creating new versions?
[17:24] <azeem> good question, depends on how popular those will be I guess
[17:32]  * marnanel nods, but it's hard to tell that before anyone's used them. :)
[17:32] <IntuitiveNipple> "Replaces" and "Conflicts" ought to cause dpkg to remove the previous package, according to Debian policy
[17:40] <Elbrus> is the PPA not just meant for people that want something special? I guess you should not worry too much about the real maintainer, and just make sure that your PPA package uses an appropriate version number: https://help.launchpad.net/Packaging/PPA#versioning
[17:40] <Elbrus> or don't I understand the problem?
[17:42] <Elbrus> marnanel: ^
[17:44] <marnanel> Elbrus: oh, pretty much for people who want bleeding-edge stuff.  I'm planning to upload it every night, though, and link to it from the Metacity page
[17:44] <marnanel> (the upstream page)
[17:46] <Elbrus> marnanel: this means your upstream? I guess you have a good relation with your maintainer?
[17:47] <Elbrus> marnanel: I guess you won't have to worry about the Ubuntu package if your targetting people that want the cutting edge. They should know that includes risks and fixing is easy: removing the PPA repository from sources.list or sources.list.d
[17:49] <Elbrus> marnanel: and of course fixing the version
[17:50] <IntuitiveNipple> For my 'bleeding edge' PPA packages I just bump the version number, add ~ppaXh (X ==release number, h == hardy), and modify the control Maintainer: field to be me.
[18:03] <marnanel> Okay-- thanks
[18:18] <marnanel> Elbrus: I don't really have a good relationship with my maintainer, or any really.
[18:18]  * marnanel is the (primary) upstream maintainer, yes
[18:18]  * marnanel doesn't really talk to the Ubuntu maintainer much, which is a shame
[18:21] <Elbrus> marnanel: I would say that that is not good practise of your maintainer. Maybe initiate some communication? I think you could both benefit (and thus the whole community).
[18:40] <csilk> oin #ubuntu-bugs
[18:40] <marnanel> Elbrus: I agree, now you mention it.  I'll email them.  Thanks.
[18:40] <csilk> join #ubuntu-bugs
[18:40] <csilk> hmm, slash button seem a little broken
[18:41] <Nafallo> /
[18:41] <Nafallo> feel free to copy one :-)
[19:09] <directhex> who feels like trying my moonlight packages for size, then?
[19:50] <marnanel> Okay, I've changed the name to "metacity", but now I can't see it at all after updating.  Did I accidentally give it a version number that's less than the hardy one?  (Hardy is "1:2.22.0-0ubuntu4", mine is "ppa~20081005a"-- "p" is after "1", isn't it?)
[19:51] <directhex> i don't know if apt understands the idea of purely alphabetical package numbers
[19:52] <stgraber> marnanel: you should try with: 2.22.0-0ubuntu5~20081005a~ppa1
[19:52] <stgraber> this one will be just higher enough to make it upgrade
[20:01] <directhex> 1:2.22.0-0ubuntu4+20081005a~ppa1
[20:01] <directhex> if it's not based on 2.22.0-0ubuntu5, don't number it as 2.22.0-0ubuntu5
[20:14] <marnanel> But it's not based on 2.22
[20:15] <azeem> marnanel: what about 1:2.23.0~20081005-0ubuntu1~ppa1 or something
[20:18] <directhex> yes!
[20:19] <marnanel> It's actually the 2.25 branch, but sure. 1:2.25.0~20081005-0ubuntu1~ppa1, then?
[20:19] <azeem> eh, right
[20:19] <azeem> sure
[20:19] <marnanel> (er, trunk isn't a branch, obviously, but you see what I mean)
[20:20] <azeem> marnanel: yeah, assuming that the next Ubuntu upload will be 2.25.0-something
[20:20] <azeem> which is a pretty good guess
[20:20] <azeem> marnanel: btw, you can run "dpkg --compare-version 1:2.25.0-0ubuntu1 gt 1:2.25.0~20081005-0ubuntu1~ppa1"
[20:20] <azeem> and check the return value
[20:33] <marnanel> azeem: thanks
[20:47] <Ayabara> Hi. I asked in #ubuntu+1 about getting a newer version of digikam-kde4 in the intrepid repos, and was directed here. Beta1 is in the repos today, but Beta4 was released a couple of days ago.
[20:47] <devfil> Ayabara: I'm working on it
[20:49] <Ayabara> devfil, great :)
[20:50] <Turl> any possibility to include a main package on universe?
[20:51] <Turl> I'd really like to see php5-gtk2 included on ubuntu, nevermind if it's in universe
[20:52] <RainCT> Turl: not for Intrepid
[20:52] <Turl> intrepid+1 ?
[20:53] <RainCT> Turl: but once Jaunty (intrepid+1) development starts, yes, it can enter universe if someone (you? :)) packages it
[20:53] <Turl> really it should be in main (as all other php parts) but I nevermind it being included in universe
[20:54] <Turl> no, I can't package :p It's too complicated. I just manage with debianPackageMaker, and that's the higher I could get xD
[21:34] <eagles051387> night
[21:57] <jdong> was it nixternal yesterday who was asking how to config touchpad settings now that there's no xorg.conf?
[21:57] <jdong> because I have the same question.
[23:11] <pochu> jdong: I think you can still configure xorg.conf. It's not required, but if you have one, it will be read
[23:14] <wgrant> jdong: You should use either System->Preferences->Mouse->Touchpad or an fdi file, depending on the settings you want... I'll pull up the docs in a sec.
[23:16] <wgrant> jdong: See https://wiki.ubuntu.com/X/Config, the "Input Configuration" section.
[23:16] <wgrant> Specifically the Synaptics part of "Input Configuration with HAL"
[23:17] <wgrant> jdong: But if you tell me which settings you need, I might be able to expose them in the GUI later this week...
[23:25] <jdong> wgrant: I need two finger scrolling config, and the ability to disable two finger tapping middle-click
[23:26]  * NCommander pokes jdong 
[23:26] <NCommander> jdong, backports await your ACK
[23:27] <wgrant> jdong: Two finger scrolling I've already implemented a UI for, but different tapping configs I haven't done... I might do that this afternoon.
[23:27] <wgrant> jdong: You can set those easily within X using xinput, or use an fdi file.
[23:28] <directhex> the mighty NCommander is here!
[23:28] <jdong> wgrant: will do
[23:28] <NCommander> directhex, do you want SSH access to one of my PPC boxes?
[23:28] <NCommander> Or do you want me to mass-build a set of packages?
[23:28] <directhex> NCommander, that would be good
[23:28] <NCommander> Standby
[23:28]  * NCommander turns on the PPC box
[23:28] <directhex> NCommander, well, the ideal would be a buildd installation i can dput to ;)
[23:29] <NCommander> directhex, seriously?
[23:29] <NCommander> How many packages are we talking about?
[23:31] <directhex> NCommander, 11. another one soon once my sponsor OKs my latest package (moonlight browser plugin)
[23:31] <NCommander> directhex, are they all in a PPA?
[23:32] <NCommander> I can simply point buildd to work against that
[23:32] <directhex> NCommander, yes, they're all in my PPA
[23:32] <NCommander> I assume they depend on each other
[23:32]  * NCommander notes you don't make my life easy ;-)
[23:33] <NCommander> If its just 11 packages, I perfer if you just built them by hand, and not bother with buildd setup and configuration; its a pain
[23:33] <directhex> the hardy sections of https://launchpad.net/~directhex/+archive
[23:34] <NCommander> directhex, and why do you need them for PPC? (I'm just curious)
[23:34] <directhex> NCommander, i had a request for ppc support
[23:34] <NCommander> I see
[23:34] <NCommander> Ubuntu or Debian PPC?
[23:35] <directhex> NCommander, it's a fairly popular repo (about 9k users on i386 and amd64)
[23:35] <NCommander> fair enough
[23:35] <directhex> NCommander, hardy. i package for ubuntu lts
[23:35] <NCommander> I need a place to upload to
[23:35] <NCommander> My machine is on a dymanic IP
[23:35] <directhex> can bounce it through my webspace, hang on...
[23:36] <NCommander> Setup an FTP server or something that can be dputted to
[23:36] <NCommander> It needs to run apt-ftparchive or dpkg-scanpackages so I can notification of the Installed state
[23:37] <NCommander> directhex, none of these look like they have crazy build-deps, so it should just work
[23:37] <directhex> crazy, moi?
[23:37] <NCommander> MOI?
[23:37] <NCommander> Mechanism of Injury?
[23:37] <directhex> me, in french
[23:38] <NCommander> I mean I can build each package indidividually it seems
[23:40] <jdong> grumble stupid hardlocks.
[23:41] <directhex> NCommander, there's no enormous reason why you couldn't, i mean they're all top-quality packages by the experts ;). i just thought it might be a PITA to do things manually
[23:41] <directhex> then again, it's a PITA to set up a buildd. theres no winning in this life
[23:41] <directhex> perhaps if i could make qemu or pearpc work, it might be easier
[23:41] <NCommander> directhex, well, setting up a buildd is one time PITA (although you have to sign the build emails)