[02:02] <jcastro> I am putting together a request for "speakers" for the next open week; is it reasonable to expect most motus follow ubuntu-devel or should I crosspost to -motu as well?
[02:02]  * jcastro gets anxious when sending out mass mails
[02:03] <cody-somerville> feel free to cross post
[02:03] <ajmitch> you won't get savaged by a pack of rabid animals
[02:05] <jcastro> oh don't worry, I can handle being savaged, I just like to not spam. :D
[02:06] <jcastro> ajmitch: long time no see, how are thing?
[02:06] <ajmitch> yeah good, how are you?
[02:07] <jcastro> ajmitch: "ahhh, release month" is the best I can say. :D
[02:07] <ajmitch> hah
[02:07] <ajmitch> yes :)
[02:07] <ajmitch> surely you're just sitting back & relaxing?
[02:08] <jcastro> heh
[02:08] <zul> spam spam spam spam
[03:15] <mcasadevall> emgent, ping
[03:40] <nxvl> jcastro: count on me for UOW
[03:40] <jcastro> nxvl: add yourself to the prep page please!
[03:40] <nxvl> jcastro: already done
[03:40] <nxvl> :D
[03:41] <nxvl> jcastro: i want to run a session explaining the development cicle, freezes, milestones and all that stuff
[03:44] <ajmitch> those sort of things are never at a decent time for me :)
[04:21] <_Andrew> If I need to package a deb twice with different data for i386 and amd64 how do I name it so that they're the same package but different debs?
[04:21] <RAOF> _Andrew: In what way different data for i386 and amd64?
[04:22] <ScottK> NCommander: Looking for some FTBFS?
[04:22] <_Andrew> Well if it's a binary package
[04:23] <ScottK> NCommander: You might want to get gtklookat to build with the current libopenvrml so the old one can be NBS'ed out.
[04:23] <persia> _Andrew, You don't want to do it that way.  Create a source package with both the amd64 and i386 blobs, and then generate the correct contents for the .deb in debian/rules
[04:23] <persia> NCommander, it's a bit of an API change.
[04:25] <_Andrew> Is there a way you know off the top of your head to check if a build is 64 or 86 in the rules file?
[04:25] <persia> I think it's DEB_HOST_ARCH
[04:25]  * persia checks
[04:27] <persia> Hrm.  Actually, I'm confused about the right rune to support crosscompilation.  Just use `DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)` for now.
[04:28] <_Andrew> ok
[04:29] <persia> If you construct your source using the right directories, you can then install from the $(DEB_HOST_ARCH)/ directory, and it ought to do the right thing (assuming you are unpacking into directories named "i386" and "amd64").
[04:29] <persia> Note for those without context : this is about packaging the nvidia-cg-toolkit binary blobs for multiverse : this is *not* a good packaging technique in most cases.
[04:34] <_Andrew> ok i'll do that then..
[04:37] <NCommander> persia, which package?
[04:38] <mdomsch> persia, -ENOSOURCE
[04:38] <mdomsch> makes you jump through hoops
[04:44] <persia> NCommander, gtklookat
[04:45] <persia> mdomsch, Yep: that's precisely the problem :)
[04:45] <NCommander> persia, what's the current libopenvrml?
[04:45] <NCommander> oh
[04:45] <NCommander> I see
[04:45] <persia> NCommander, build-dep is libopenvrml-dev (unversioned)
[04:46] <NCommander> ah
[04:46] <NCommander> That makes sense :-)
[04:46] <persia> I spent a few hours on it last night : there's more changes than I usually like.
[04:46] <NCommander> How far did you get?
[04:47] <persia> My current version still doesn't parse as valid C.
[04:47] <persia> (mind you, this is probably because half of it is C++, but it still ought parse)
[04:48] <NCommander> Ouch
[04:48] <NCommander> I take it this is going to be a major headache?
[04:49] <persia> 383 days since the last Debian upload, so no hints there.
[04:49] <NCommander> what about upstream?
[04:49] <persia> Well, someone has to learn the libopenvrml API, I suspect
[04:50] <NCommander> Argh, I *Hate* quilt
[04:50] <persia> upstream doesn't distribute it in the newer releases.
[04:50] <NCommander> wait, what?
[04:50]  * persia looks for evidence of consolidation
[04:55] <persia> NCommander, There's a reference in the upstream changelog from 2006: "Removed lingering reference to lookat".  Given that the version of openvrml we currently ship happens to produce lookat, I suspect that the issue is larger than an API.  I should have looked at this last night.
[04:56]  * NCommander checks popcon on gtklookat
[04:56] <NCommander> Removal may be the correct solution
[04:56] <persia> I'm thinking that.
[04:56] <NCommander> Argh
[04:57] <NCommander> why does ubuntu's popcon suck compared to debian's :-/
[04:57] <persia> How do you mean?
[04:57] <NCommander> On popcon, you can look up specific packages without having to open the by_inst log which is huge
[04:58] <persia> Ah, yes, that would be frustrating.
[05:00] <NCommander> persia, its got 1 recent usage on Debian
[05:00] <NCommander> and I don't even see it on the Ubuntu installation lists
[05:00] <NCommander> (aka, no one who has popcon has it installed ...
[05:02] <NCommander> persia, so I think it can be safely removed :-)
[05:05] <persia> NCommander, Sounds good.  I'll file a bug.  I think openvrml needs a major packaging overhaul, based on upstream NEWS.  I'm strongly of the opinion that the current package has some issues.
[05:05] <NCommander> It likely needs to be fixed in Debian
[05:05] <NCommander> Or should be
[05:06] <persia> Oh, certainly, but I suspect the number of users is sufficiently small that it can happen in squeeze.
[05:06] <NCommander> persia, looking at popcon (I made a type) there are 18 recent users
[05:07] <NCommander> But 980 installations, 56 recent users, 18 recent upgrades
[05:07]  * NCommander isn't used to reading popcon data
[05:08] <persia> NCommander, Of gtklookat?
[05:08] <NCommander> yeah
[05:09] <NCommander> :-/
[05:10] <persia> OK.  So, it wants porting then, or people want working VRML?
[05:10] <NCommander> persia, gtklookat was dropped upstream
[05:10] <persia> Yes, a couple years ago.
[05:10] <NCommander> I think dropping it is the correct solution
[05:11] <NCommander> persia, it looks like the gtklookat plugin was replaced with a browser plugin or something
[05:12] <persia> Oh, I don't disagree with that, I'm just wondering how to pander to the users.
[05:12] <NCommander> so its useless if your using modern versions of the library
[05:12] <persia> There's a plugin and a standalone app.
[05:12] <NCommander> the functionality probably went into the standalone app
[05:12] <persia> There's also an RC bug in Debian about openvrml FTBFS (which I'm checking).  It may be worth fixing in Debian sooner, rather than later.
[05:13] <persia> And according to Debian bug #459242 , it doesn't even work correctly :)
[05:14] <NCommander> persia, where's the FTBFS bug?
[05:14]  * NCommander was looking at RC bugs
[05:14] <NCommander> I can get that NMUed in Debian
[05:15] <persia> NCommander, http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=openvrml&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious&repeatmerged=no has two of them.
[05:15] <persia> I'd suggest the new upstream to be the solution, and not shipping in Lenny.  I'm testing in intrepid, but suspect I'll feel the same about that.
[05:16] <persia> Note that new upstream requires NEW, so probably doesn't belong in either lenny or intrepid.
[05:17] <NCommander> So what do we do?
[05:17] <NCommander> Drop openvrml?
[05:17] <persia> (plus it needs ubuntu delta for mozilla-ness, so sync isn't right either).
[05:18] <persia> I say we drop gtklookat, and drop openvrml if my build-test fails.  gtklookat belongs on the blacklist, but I don't think we should blacklist openvrml, and we can try to fix it for squeeze/jaunty.
[05:18] <NCommander> We have openvrml-atlook now
[05:18] <NCommander> So the newer versions have replacements
[05:18] <persia> Take a look in debian/patches :)
[05:18] <NCommander> ?
[05:19] <persia> We have openvrml-lookat.  Upstream doesn't.
[05:19] <NCommander> Can we drop like the 20 odd versions of this library?
[05:19] <NCommander> (there are like four seperate versions ...)
[05:20] <persia> I only see libopenvrml8 and the NBS libopenvrml5c2a
[05:20] <StevenK> persia: gtklookat is quite stuffed
[05:21] <StevenK> persia: Upstream doesn't care any more, and it needs significant rewriting to deal with the API changes that openvrml has gone through
[05:21] <persia> StevenK, Yeah.  I'm filing a removal bug as soon as the openvrml build fails.  Perhaps you'd like to action it once I'm done?
[05:21] <StevenK> persia: Perhaps
[05:22] <persia> It seems we have a few other VRML viewers, so I'm not very worried.
[05:22] <NCommander> persia, I have libopenvrml4, 3, and 0
[05:23] <NCommander> or
[05:23] <NCommander> More specificly
[05:23] <persia> NCommander, If your apt-cache clean?
[05:23] <persia> NCommander, Is your sources.list trim?
[05:23] <NCommander> apt-cache clean says command not found
[05:24] <persia> Yes.  making a clean apt-cache comes from running any of the many apt-cache affecting tools in "update" mode.
[05:24] <NCommander> How do I do that if apt-cache clean doesn't exist ;-)?
[05:24] <persia> Mind you, you'll want a trim sources.list before you do that.
[05:24] <NCommander> It's just intrepid
[05:24] <NCommander> And my PPA
[05:24] <NCommander> oh wait, I have the REVU sources list on it
[05:25] <NCommander> O_o;
[05:25] <persia> No, you run an update from adept, synaptic, update-manager, apt-get, aptitude, python-apt, libept, or something similar.
[05:25] <persia> That cleans the apt-cache.
[05:25] <NCommander> ok
[05:25] <NCommander> Trying
[05:25] <persia> (but only if you have a good sources.list)
[05:25] <NCommander> You don't have it on yours?
[05:25] <NCommander> (if you don't, then its not going to irk me)
[05:25] <persia> No.
[05:25] <NCommander> ok
[05:25] <persia> Try updating a build chroot, and checking the apt cache therein.
[05:26] <NCommander> So what do we do now?
[05:26] <NCommander> (while I check)
[05:26] <persia> If you find lots of libopenvrmls, please hunt and kill them.  I'll take care of 5c2a and 8.
[05:27] <StevenK> I'll deal with 5c2a
[05:27] <StevenK> Along with gtklookat
[05:27] <persia> Cool.  That just leaves me 8.
[05:27] <NCommander> anything else I can do?
[05:27] <StevenK> 8 is also NBS?
[05:27]  * persia files the gtklookat bug quick so StevenK has an excuse.
[05:27] <persia> No, but I believe it to be FTBFS, and require a new upstream to be sensible.
[05:28] <NCommander> wait
[05:28] <NCommander> Intrepid went frozen?
[05:28] <StevenK> Right
[05:28] <NCommander> when did that happen?
[05:29] <StevenK> Yesterday]
[05:29] <StevenK> s/]//
[05:29] <lifeless> after it wasn't frozen
[05:29] <StevenK> Hah
[05:29]  * NCommander whacks lifeless 
[05:29] <NCommander> so what does that mean specifically?
[05:29] <StevenK> It won't thaw before release. That makes me sad.
[05:29]  * lifeless releases the hounds
[05:29]  * NCommander eats the hounds
[05:29]  * NCommander uses a phoenix down on lifeless
[05:29] <lifeless> thats gonna smart
[05:30] <StevenK> "Ow! That's going to bleed when my heart beats!"
[05:30] <persia> NCommander, It means that if you upload something that changes anyone's build images, and you don't have an RC reason, you'll get smacked.
[05:30] <lifeless> NCommander: it means that no changes without approval from here on in
[05:30] <NCommander> Right
[05:30] <NCommander> Ok
[05:30] <NCommander> I was expecting that
[05:30] <NCommander> I just didn't realize the actual status of the archive changed in launchpad
[05:30] <persia> It's the only way to enforce the approvals.
[05:30] <StevenK> For universe/multiverse, not yet
[05:30] <StevenK> Read -devel-announce
[05:31] <persia> StevenK, Well, it still needs approvals, but it's a little easier to get them.
[05:31]  * NCommander should subscribe to that ;-)
[05:31]  * StevenK thumps NCommander 
[05:31]  * NCommander looks forward to finishing his first cycle with DIF jaunty
[05:31]  * NCommander thumps StevenK 
[05:31] <persia> StevenK, bug #284768 for posterity.
[05:32]  * StevenK logs into cocoplum again
[05:32] <NCommander> cocoplum?
[05:32] <NCommander> Is there ANY logic behind canonicals naming scheme?
[05:32] <persia> No.
[05:32] <_Andrew> sorry guys one last question, how do I authenticate my packages when I download them from myppa?
[05:32] <NCommander> _Andrew, you can't
[05:32] <NCommander> Limitation of PPAs
[05:32] <persia> _Andrew, Copy them to some other repo, and sign that repo.
[05:32] <NCommander> or do that
[05:33] <_Andrew> So I can't distribute a key or something and download them from myppa?
[05:33] <persia> Nope.
[05:33] <_Andrew> That sucks
[05:33] <_Andrew> hehe
[05:33] <NCommander> _Andrew, its a known bug with Launchpad, but the fix isn't trival or even clear
[05:34] <StevenK> persia: gtklookat and libopenvrml5c2a killed
[05:34] <persia> StevenK, Cool.  I suspect I'm going to want all of openvrml gone (but not blacklisted), but that can wait.
[05:34] <NCommander> StevenK, that's an awesome power
[05:34] <StevenK> Oh yeah
[05:35]  * StevenK blacklists gtklookat
[05:35] <_Andrew> ok it doesn't really matter.. I've been packaging all the things I need for people to download to compile my code.. Here you can check it out.. https://launchpad.net/~andrewfenn/+archive
[05:35] <_Andrew> I'm pretty proud since i've never packaged before
[05:35] <NCommander> _Andrew, you can submit your packages for submission into Ubuntu via REVU
[05:35] <NCommander> (although you'll have to wait for Jaunty to open)
[05:35] <StevenK> NCommander: Hmm?
[05:36] <NCommander> StevenK, the power to zap packages ;-)
[05:36] <persia> NCommander, This particular package would do better to go through Debian, as it's a repackaging to take advantage of upstream license changes, and would solve a number of complex issues.
[05:36] <StevenK> NCommander: It's quite fun
[05:36] <NCommander> persia, I can see about getting it NMUed since upstream is quite dead
[05:36] <persia> OK.  Last meaningful NBS issue seems to be octave-gpc.
[05:36] <_Andrew> I submitted a bug at debian already
[05:36] <NCommander> persia, I have someone willing to do the NMU, which mean once squeeze is opened, I can look at getting it orphaned and then updated
[05:37] <persia> NCommander, I think you're talking about a different package than _Andrew and I.
[05:37] <_Andrew> and in Ubuntu linking to the debian bug and also put in where to find the deb I made incase anyone wants it
[05:37] <NCommander> persia, I'm talking about openvrml
[05:37] <persia> _Andrew, Did you run lintian against your package (nvidia-cg-toolkit) ?
[05:38] <_Andrew> I have no idea hehe
[05:38] <NCommander> That probably means no
[05:38] <persia> NCommander, Getting that updated would be good.  You might want to check with sam about dropping gtklookat as well.
[05:38] <NCommander> _Andrew, lintian is a utility to find common bugs in packages
[05:38] <NCommander> Try running lintian on your .dsc and on your debs
[05:38] <_Andrew> oh right, I didn't do that for any of them
[05:39] <NCommander> _Andrew, if your interested in getting those packages in Debian, I'd be glad to help you with that
[05:40] <persia> _Andrew, You've generated a native package.  You don't want to do that.
[05:40] <NCommander> Argh
[05:40]  * NCommander just possibly found an RC bug
[05:40] <NCommander>   libfam-dev: Depends: libfam0 (= 2.7.0-13.3ubuntu1)
[05:40] <NCommander> Can't install
[05:40] <NCommander> can someone confirm?
[05:40]  * StevenK checks
[05:40] <_Andrew> I ran lintian against my dsc and it doesn't do anything.. that's good right?
[05:41] <persia> That's good.
[05:41] <NCommander> It means there are no stupid packaging bugs, so yes :-)
[05:41] <StevenK> _Andrew: It does do stuff, it just doesn't report anything
[05:41] <persia> You also want a debian/rules get-orig-source rule to explain how to construct the source files.
[05:41] <NCommander> _Andrew, most *NIX utilities say nothing if everything is ok
[05:41] <_Andrew> yeah I know but well.. sometimes you just wanna confirm..
[05:42] <NCommander> :-)
[05:42] <persia> _Andrew, Also, you are editorialising in debian/copyright : don't do that.  Do identify the upstream authors and copyright holder.
[05:42] <NCommander> StevenK, can you install libfam-dev?
[05:42] <_Andrew> Which file?
[05:42] <StevenK> NCommander: Yes
[05:42] <_Andrew> the toolkit?
[05:42] <NCommander> Ok
[05:43] <NCommander> hrm
[05:43]  * NCommander looks at why this went boom
[05:43] <StevenK> NCommander: Direct from archive.u.c to my machine
[05:55] <NCommander> persia, are you on -release?
[05:55] <NCommander> oh
[05:55] <NCommander> TheMuso, ping?
[05:56] <TheMuso> NCommander: pong
[05:56] <NCommander> TheMuso, can I get an ack for an upload to universe?
[05:56] <TheMuso> NCommander: bug?
[05:57] <StevenK> You don't need an ack currently, I think
[05:57] <NCommander> The archive is frozen
[05:57] <persia> NCommander, Very much not.
[05:57] <NCommander> So doesn't -release have to unfreeze that package
[05:57] <NCommander> or do I misunderstand?
[05:57] <TheMuso> NCommander: only for upstrea/Feature freeze.
[05:57] <TheMuso> upstream
[05:57]  * NCommander is familiar with Debian freezes
[05:57] <NCommander> but not Ubuntu
[05:58]  * persia files bug #284775
[05:58] <NCommander> So who gets a package to enter the archive if archive state == frozen?
[05:58] <StevenK> main/restricted requires -release to say yes
[05:58] <persia> NCommander, An archive admin needs to explicitly accept it.  They will only do so based on the guidance of the relevant release team.
[05:58] <NCommander> ah
[05:58] <NCommander> I see
[05:58] <NCommander> that makes sense
[05:58] <NCommander> ok
[05:58]  * NCommander runs and hides now ;-)
[05:59] <persia> StevenK, Technically, universe/multiverse requires MOTU-release to say yes, but there's been a semi-blanket "yes" said for the next few days.
[06:02] <persia> OK.  It's archive-consistency season.  I've 76 packages on amd64 that cannot install.  Could people with other architectures please run `apt-cache unmet -i | grep ^Package  | wc -l` and report the results?  I suspect we've some work to do.
[06:03] <StevenK> persia: Does intrepid_probs.html agree with you?
[06:03] <persia> StevenK, intrepid_probs.html is only 2 architectures, and only main.  It doesn't tend to be a very interesting source of stuff to do.
[06:04] <persia> Everything in there is either langpacks or kernels.
[06:04] <StevenK> persia: Oh, yes. libhdf5-serial-1.6.5-0 essentially only contains octave-gpc to be fixed.
[06:04] <persia> intrepid_outdate.html is a little more interesting
[06:04] <StevenK> persia: octave-gpc looks to be very hard to get working against octave 3.0
[06:04] <persia> StevenK, Yeah.  I looked at that, and deleted the results after fiddling a bit.
[06:05] <persia> It needs someone who actually understands octave.
[06:05] <StevenK> I managed to get it compiling stuff, but the API has changed
[06:06] <StevenK> Since configure.in was written by someone who assumed that $major_version is always 2
[06:07] <persia> NCommander, You like playing with goats, right?
[06:07] <NCommander> persia, er?
[06:07] <NCommander> goats?
[06:07]  * persia finds an image from the O'Reilly catalog
[06:07] <NCommander> What needs porting?
[06:08] <persia> octave-gpc
[06:08] <NCommander> I don't know anything about octave
[06:09] <persia> http://sources.redhat.com/autobook/cover.jpg
[06:09] <NCommander> What does upstream have to say on the subject?
[06:09] <persia> (that should explain the goats)
[06:09] <NCommander> It does
[06:09] <NCommander> But it still sounds wrong
[06:10] <StevenK> octave-gpc |    0.1.6-5 | unstable/contrib | source, amd64, arm, ia64
[06:10] <StevenK> I guess that explains a little
[06:10] <persia> 219 days old (needed 10 days)
[06:10] <NCommander> It's a multiverse package?
[06:10] <NCommander> It's got no rdepends
[06:11] <NCommander> 17152 octave-gpc                       488     4    97     2   385 (Debian Octave Group)
[06:12] <persia> NCommander, It's GPL multiverse though, which makes it less unpleasant.
[06:12] <NCommander> so 488 installs, 4 regular users, 97 old users, two recent upgrades, and 384 unknowns
[06:12] <persia> http://changelogs.ubuntu.com/changelogs/pool/multiverse/o/octave-gpc/octave-gpc_0.1.6-5/copyright
[06:13] <NCommander> persia, looks dead upstream
[06:14] <persia> StevenK, How do you feel about removal?
[06:14] <NCommander> Four users, no rdepends
[06:16] <StevenK> I'd like to discuss with pitti, first
[06:16]  * NCommander checks debian popcon
[06:16] <sbeattie> persia: 47 on i386 here.
[06:17] <persia> sbeattie, That's a much smaller number, which is good, but still a bit to do :)
[06:20] <persia> NCommander, Not so dead upstream.  Last commit was only 8 months ago.
[06:21] <NCommander> I can't see a stable release for it
[06:30] <sbeattie> persia: mind you, edos-debcheck finds 99 on i386. Not sure why some don't show up in apt-cache unmet -i.
[06:30] <persia> Lack of stable release doesn't mean dead.
[06:30] <persia> sbeattie, Recommends.
[06:32] <persia> http://qa.ubuntuwire.com/debcheck/ provides a pretty good picture of everything that needs doing, but it's *lots* of packages.  I think apt-cache unmet -i is the first stage : once those are complete, it's worth chasing the rest.
[06:40] <NCommander> apt-cache unmet -i?
[06:40] <StevenK> Run it
[06:41] <sbeattie> persia: odd, neither apt-cache unmet -i nor http://qa.ubuntuwire.com/debcheck/ list xxkb as uninstallable, but it definitely is, though it just needs a rebuild.
[06:41] <dholbach> good morning
[06:42] <sbeattie> (well, I have no idea if the rebuilt package actually works as expected; it did things, but it was not obvious that it was behaving correctly and the online documentation for it is in russian)
[06:42] <persia> sbeattie, Very odd indeed.
[06:42] <persia> Well, that's a help.  Is there a bug for that?
[06:43] <sbeattie> bug 76260
[06:43] <geser> good morning dholbach
[06:44] <dholbach> hi geser
[06:44] <didrocks> good morning everyone ! :)
[06:44] <dholbach> hi didrocks
[06:44] <didrocks> hi dholbach !
[06:45] <NCommander> how goes it dholbach
[06:45] <dholbach> NCommander: good good, slowly waking up :)
[06:45]  * NCommander gives dholbach coffee
[06:45] <dholbach> gracias :)
[06:45] <geser> dholbach: http://xkcd.com/490/ ?
[06:46] <dholbach> geser: no no, I got up already :-)
[06:50] <persia> sbeattie, Just for future note, it's a good idea to subscribe the sponsors when you attach a debdiff to a bug.
[06:52] <sbeattie> persia: I know, I was hoping for some confirmation that the ppa package actually worked correctly first; if it didn't, I was going to request it just be dropped.
[06:52] <persia> sbeattie, For exceedingly unloved packages like that, we usually just test a bit locally, and if it doesn't break anything, upload, as it's probably better than the previous state.
[06:53] <persia> Mind you, the package still build-deps on x-dev, which is non-ideal, but that can be fixed for Jaunty.
[07:41] <highvoltage> moring dholbach
[07:41] <dholbach> hiya highvoltage
[07:41] <BugMaN> morning all
[07:41] <highvoltage> dholbach: will http://www.jonobacon.org/?p=1345 be available on http://video.ubuntu.com/motuvideos/ as well?
[07:41] <highvoltage> hi BugMaN
[07:42] <dholbach> highvoltage: I'll ask him for the original
[07:43] <highvoltage> thanks dholbach!
[09:27] <huats> morning everyone !
[09:27] <directhex> is it? :o
[09:31] <didrocks> morning huats ;)
[09:31] <huats> morning didrocks
[10:13] <james_w> lfaraone: congratulations
[10:24] <morgs> james_w: morning!
[10:25]  * morgs is looking for a good example of how to handle binary package renames. Provide a transition package?
[10:26] <slytherin> morgs: what is the reason for rename?
[10:26] <morgs> slytherin: we synced from debian which had some different names to hardy - e.g. hulahop -> python-hulahop
[10:27] <morgs> and sugar-toolkit -> python-sugar-toolkit
[10:27] <morgs> so it's for upgrades from hardy
[10:28] <slytherin> morgs: do the new packages replace any files form the old one? I think you might want to take a look at how it was done for bluez.
[10:28] <slytherin> morgs: bluez replaces everything that was present in bluez-utils.
[10:29] <morgs> slytherin: OK thanks, it's basically a rename, so if you had hulahop installed, you now want python-hulahop installed to replace hulahop
[10:29] <morgs> I'll look at bluez
[10:57] <doggymenz> dude, put openoffice3 and blender248 in repo
[10:57] <doggymenz> there is old version in repo
[10:57] <orly_owl> ok dude
[10:58] <doggymenz> thx dude
[10:58] <orly_owl> np
[11:03] <james_w> hey morgs
[11:38] <slytherin> persia: there?
[11:43] <jrib> python-webkitgtk is broken and fails to build from source :/
[12:01] <directhex> webkit-sharp is great and builds fine from source. boo to python
[12:03] <POX> lol
[12:05]  * jrib sees the problem methinks and boo sharp :)
[12:06] <persia> slytherin, kinda, but distracted.
[12:19] <slytherin> persia: when you have time, just let me know if we should get merge change - http://packages.qa.debian.org/libj/libjogl-java/news/20081012T161521Z.html
[12:22] <sistpoty|work> hi folks
[12:22] <persia> slytherin, No, we don't want to do that while it's frozen.
[12:23] <slytherin> persia: So do you mean we can get it past RC?
[12:23] <slytherin> s/past/post
[12:23] <persia> slytherin, I mean I don't think it's worth trying to push it.  We're not going to get a multiverse->universe change, so the license change isn't so important.
[12:23] <lfaraone> thanks, james_w
[12:25] <slytherin> Ok.
[12:32] <slytherin> persia: and what about this - http://lists.debian.org/debian-java/2008/10/msg00014.html
[12:44] <persia> slytherin, How many packages?  If it's only three or four, it's worth fixing.  If it's more, it's probably not worth fixing.
[12:45] <jrib> when is it ok for pywebkitgtk_1.0.1.orig.tar.gz to be modified?
[12:46] <jrib> from whatever the project actually puts out
[12:46] <persia> jrib, When it contains stuff you can't distribute because of the licensing.
[12:46] <persia> jrib, The rest of the time, you shouldn't do that.
[12:48] <jrib> persia: thanks
[12:51] <persia> jrib, Actually, there's also a repack exemption.  If upstream produces a .bz or a .zip or something, we can repack to orig.tar.gz, but the contents must remain identical in that case.
[13:00] <NCommander> persia, Launchpad still doesn't accept orig.tar.bz2's?
[13:01] <persia> NCommander, I haven't tried in a while, but I've not seen an announcement that it does.  Ask in #launchpad to be sure.
[13:01] <NCommander> persia, I'll fire an upload to my PPA at some point to test
[13:05] <persia> DktrKranz, Would you have time to test an -rt kernel for intrepid this evening?
[13:08] <slytherin> persia: two packages, statcvs and jta
[13:09] <slytherin> persia: A sync is preferred, right? Those packages are already fixed in Debian.
[13:09] <persia> slytherin, Pushing two packages to drop two obsolete libraries is definitely worth it.  Please proceed, and give me the bug numbers.
[13:09] <persia> A sync is preferred iff there is nothing else that is worrisome.
[13:09] <persia> If that's the only change, certainly.  If the other changes are also critical, yes.  Otherwise, backport the changes.
[13:13] <slytherin> persia: The latest changelogs are not available on packages.debian.org and hence request-sync is giving trouble. I will tell you bug numbers by tomorrow.
[13:14] <persia> slytherin, Sounds good.
[13:15] <doggymenz> please update python-pyglet in repo from 1.0 to 1.1
[13:17] <persia> doggymenz, The archive is frozen for the intrepid release.  What does the new version bring that would be worth a possible regression?
[13:17] <doggymenz> the example code i download dont run, because its coded for the old version
[13:18] <doggymenz> the documentation i lookup doesnt work
[13:18] <doggymenz> because its documentation for new version
[13:18] <doggymenz> and there i stand with my dick in my hand using an old version
[13:18] <DktrKranz> persia: sure... if I find time to break other packages with "security fixes" :D
[13:18] <doggymenz> maybe if i would have the new version, i wouldnt have this problem, not being able to grab keyboard events from NUMPAd
[13:18] <DktrKranz> persia: where can I find it'
[13:19] <persia> DktrKranz, Bug #281276 has a pointer.
[13:20] <doggymenz> also  if archive is frozen, then put it in backports
[13:20] <DktrKranz> persia: mind subscribing me at the bug report? I'm lacking a browser right now
[13:21] <persia> doggymenz, It can probably be put in backports for intrepid in early November.  At this point, there's nowhere from which to backport it.
[13:21] <persia> DktrKranz, Not at all.
[13:21] <persia> DktrKranz, even w3m or elinks?
[13:21] <DktrKranz> yep
[13:21] <doggymenz> its in debian-unstable
[13:25] <morgs> I need to add a ___.install for a package where I'm adding a separate transitional package. Is there any quick way to generate that?
[13:28] <james_w> morgs: does the package need to contain anything?
[13:28] <DktrKranz> NCommander: all GNAT related packages are in hardy-proposed \o/
[13:29]  * NCommander sprays some bugspray on -proposed
[13:29] <NCommander> DktrKranz, finally :-)!
[13:29] <DktrKranz> NCommander: I plan to have some testing during weekend, mind giving a look you too?
[13:30] <morgs> james_w: no, the transitional package doesn't need anything, but it's like the sugar package when we added sugar-activities... the files in the main package aren't installing
[13:30]  * NCommander would have to install Hardy on something
[13:30] <james_w> morgs: ah, I see.
[13:30] <persia> NCommander, virtualisation is the key
[13:30] <james_w> morgs: not really, depends what's in it, just installing usr/ might be a good start
[13:30] <directhex> hm... suggestions on debian/watch of a svn repo?
[13:31] <DktrKranz> NCommander: a hardy pbuilder should be enough for most packages
[13:31] <NCommander> persia, its a good thing I hacked VTx in my BIOS to on
[13:31] <morgs> james_w: so putting debian/tmp/usr/* would install anything in /usr/lib/python2.5/site-packates/.../.../ etc?
[13:31] <DktrKranz> (if not all)
[13:31] <james_w> morgs: I believe so
[13:31] <morgs> james_w: thanks, that's great.
[13:32]  * james_w realises he hasn't actually done much packaging for a long time
[13:32] <persia> james_w, You've been coding, which makes up for that.
[13:32] <slytherin> doggymenz: we only post sources from debian. The way backports work - the version has to enter first in the latest unstable version and built there without problem. Then one can request for backport and it will be evaluated. One there are no build problems for backport it will made available as test build. Only after confirmation it will be actually out in -backports repository.
[13:33] <slytherin> just curious, has anyone here ever tried coreboot?
[13:33] <NCommander> slytherin, yes, awhile back
[13:34] <slytherin> NCommander: how good is it? And what are the chances that I would put my system in completely unusable state?
[13:34] <NCommander> slytherin, pretty awesome, and pretty high if your hardware isn't supported
[13:34] <james_w> on that note, can someone check this for me please? http://paste.ubuntu.com/58790/
[13:36] <doggymenz> slytherin, well pyglet is in debian-unstable, so someone should put it in backports... also someone should put blender and openoffice3 there too
[13:37] <NCommander> doggymenz, we only backport from intrepid expect in extremely rare cases
[13:37] <NCommander> (or more specifically the current release)
[13:37] <persia> james_w, Which file does libgems-ruby share with rubygems?
[13:37] <james_w> persia: for the Replaces?
[13:37] <persia> james_w, Err.  Nevermind.  I see what you're doing.
[13:37] <persia> No, the conflicts.
[13:38] <persia> james_w, Only issue I see is that you fail to mention that the rubygems package is a transitional package, and may be removed.
[13:38] <james_w> in the description?
[13:38] <persia> Yep.
[13:38] <james_w> I pulled it from Debian, but I agree
[13:38] <persia> See e.g. the x-dev description.
[13:38] <james_w> is there some magic if you put "(transitional package)" in the short description?
[13:38] <doggymenz> well, im getting sick of living 6+ months with old releases, while everyone else can happily enjoy the latest stuff
[13:40] <persia> james_w, Only in terms of compliance to conventions.  Some people grep for it, but it's not common.
[13:40] <blanktheserver> Blender isn't a serious thing to not have in the repos, since it's only an application it's easy to compile manually. Although the latest versions are really pushing forward.
[13:41] <james_w> persia: http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-transition
[13:41] <james_w> persia: that's what I was remembering
[13:41] <james_w> I don't think it's a major use case though
[13:41] <persia> james_w, Like I said.  Some people grep for it, but it's not common :)
[13:41] <slytherin> doggymenz: Ok. I was talking about unstable release of Ubuntu. Ubuntu gets source from Debian and they have to be built on Ubuntu build servers.
[13:42] <NCommander> uh, doggymenz, Debian releases once every one to two years. You can run intrepid if you want more up to date things, and jaunty opens in a few weeks which will import everything from sid
[13:42] <doggymenz> slytherin, im running 8.10 intrepid ibex, and i must use old packages :(
[13:43] <NCommander> doggymenz, we're in feature freeze because we are about to do a release.
[13:43] <slytherin> doggymenz: Can't help much here.
[13:43] <doggymenz> NCommander, yeah.. but after the release, i still wont get any new packages, will i ?
[13:43] <NCommander> doggymenz, we can backport to intrepid then.
[13:43] <NCommander> doggymenz, or you can run jaunty
[13:44] <NCommander> (the package will enter jaunty, then we can backport it to hardy or intrepid if we get a request)
[13:44] <blanktheserver> doggymenz, why not simply compile the latest and greatest, the things you mentioned are simple to build manually. I'm sure there's even ppa's with packages for whatever you want.
[13:44] <slytherin> blanktheserver: what about blender? The 2.46 version is already there in intrepid
[13:45] <blanktheserver> 2.46 isn't the latest.
[13:45] <doggymenz> NCommander, no i cant run jaunty, because if i do that, my system will break and my computer wont be useable
[13:45] <blanktheserver> slytherin, in fact 2.48 was just released.
[13:45] <slytherin> blanktheserver: We won't get 2.47 in repos now. If there are any particular bug fixes you would like, log a bug, someone will try to backport the fix.
[13:46] <doggymenz> i want all new features
[13:46] <blanktheserver> slytherin, yes I know, I don
[13:46] <doggymenz> i want 2.48
[13:46] <blanktheserver> doggymenz, as I said, compile it yourself
[13:46] <doggymenz> :(
[13:46] <blanktheserver> It's really not hard.
[13:46] <doggymenz> i shouldnt need to, it should "just work"
[13:47] <doggymenz> windows users are never stuck with old software, they can always enjoy the benefits of the latest software as soon as it gets released
[13:47] <blanktheserver> doggymenz, the latest and greatest has a tendency to not "just work" hence its non-inclusion.
[13:47] <doggymenz> it always works on windows
[13:47] <doggymenz> i downloaded blender 2.48 and openoffice3 on windows xp, and it worked
[13:48] <persia> doggymenz, You can certainly download and install any version you want.  It might even work.  As with Windows, it's not included in the box.
[13:48] <doggymenz> well, if its in the repo, i can certainly download and install it... if its not in the repo, well, then tough luck
[13:49] <Laney> No, not tough luck. If it's not in the repo then you can get it from source yourself.
[13:49] <blanktheserver> doggymenz, it is not hard to install software from source.
[13:49] <blanktheserver> And you could do the same for linux doggymenz, but that's not the point. Beta software as well as latest release software isn't supported because it isn't tested, where the latest and greatest features might matter to you, other people just want a stable operating system. If you want the latest, compile it yourself or get it from a ppa.
[13:58] <blanktheserver> I might also add doggymenz, that blender doesn't even need to be compiled.
[13:58] <blanktheserver> It comes pre-built.
[14:05] <doggymenz> blanktheserver, yes it is. you have to read guide to know what commands to type, make, make install, ./configure, etc... and then it never compiles because of dependencies, if you get the dependencies it still wont compile. now if you manage to compile it, and install it.. then you cant uninstall it
[14:06] <stefanlsd> Im using pbuilder chroot  with pbuilder --login . It seem to replicate things properly. like  installing a package doesnt give me the debconf dialog boxes. is that normal?
[14:06] <blanktheserver> doggymenz, you're making it harder than it is.
[14:06] <persia> stefanlsd, You should get just as many debconf prompts in the chroot, unless debconf is configured to be non-interactive or something.
[14:06] <blanktheserver> doggymenz, ./configure then make then make install then if needed, make uninstall
[14:07] <doggymenz> oh
[14:07] <doggymenz> its never been that simple for me
[14:07] <StevenK> NCommander: Is is done yet?
[14:07] <doggymenz> it always complained about dependencies, i tried get thme, it still woudlnt compil
[14:07] <blanktheserver> doggymenz, obviously you need the dependencies too, but they are just a google and an apt away.
[14:08] <stefanlsd> persia: mmm. not getting any for mysql-server (cant remember if that actually had) - and also bugzilla3  (which def does have if i install it on my live intrepid machine).  so like you said, unless they look for some environment setting and dont do it then...
[14:08] <persia> stefanlsd, try running dpkg-reconfigure debconf and then doing the installs :)
[14:10] <doggymenz> i just installed pyglet 1.1 and it solved the problem of keyboard events not being able to catch numpad number keys
[14:10] <stefanlsd> persia: dpkg-reconfigure debconf does nothing, and still dont get dialog boxes :)
[14:11] <persia> stefanlsd, Hrm.  Dunno then.  Sorry.
[14:12] <stefanlsd> persia: hehe :)   do you think you would be able to test your intrepid chroot for me pleeease :)  - just wanna see if its a specific thing, or i've got a local issue
[14:12] <persia> stefanlsd, pastebin the test case
[14:13] <persia> stefanlsd, Note that my chroots were built with debootstrap --buildd which may affect things.
[14:15] <ScottK> sistpoty|work: I've updated my draft libspf2 package.  If you could have another look it'd be greatly appreciated.
[14:16] <james_w> do we have a "missing package" report that would help with knowing where we may need a transitional package?
[14:16] <james_w> or would that be too noisy to be useful?
[14:16] <persia> james_w, debcheck has a list of broken dependencies, which may help identify that.
[14:16] <slytherin> persia: does that --buildd option replicate our build servers?
[14:17] <ScottK> james_w: I think it's an excellent idea.  We do have a generic problem of people getting left with orphaned packages on upgrades.
[14:17] <persia> slytherin, No, it replicates hypothetical buildds.
[14:17] <james_w> I'm sure we miss loads for LTS->LTS
[14:17] <james_w> I'll try and work on it some time
[14:17] <stefanlsd> persia: http://pastebin.ubuntu.com/58804/   (although its a potential 20mb download - so if thats an issue, its ok - will find another way to test!)
[14:17] <ScottK> james_w: Now is the time to start working on it to be ready for the next LTS -> LTS.
[14:18] <slytherin> james_w: have you taken look at broken depends report?
[14:18] <persia> stefanlsd, No issues: I have plenty of bandwidth.
[14:18] <james_w> slytherin: the debcheck one on ubuntuwire?
[14:18] <persia> stefanlsd, which arch?
[14:19] <stefanlsd> persia: x86
[14:23] <slytherin> james_w: yes, that one
[14:23] <james_w> slytherin: yeah, but this is something slightly different I think
[14:23] <james_w> slytherin: or am I missing something?
[14:24] <persia> stefanlsd, You understated the download : it's 268MB for me.
[14:25] <stefanlsd> persia: aah. sorry.  i guess you could do --nodeps.  really only wanna see if the debconf runs
[14:25] <persia> stefanlsd, No worries : I just need a few extra minutes.
[14:26] <stefanlsd> heh. i need to get out of SA :)
[14:27] <morgs> stefanlsd: or wait a few years for all that bandwidth to reach the last mile... :)
[14:27] <ScottK> stefanlsd: Move to NZ for a while and then move back and bandwidth in ZA will seem wonderful.
[14:28]  * RainCT reminds that there's a voting about REVU Days on http://ubuntuforums.org/showthread.php?p=5925205
[14:28] <stefanlsd> ScottK: really. Didnt think it was bad in NZ...
[14:28] <slytherin> james_w: What I am saying is you can look into broken depends for important packages and see if something is dropped as compared to hardy. Not an automated task though.
[14:28]  * ScottK reminds RainCT that most developers don't really use the forums.
[14:29] <ScottK> stefanlsd: Dunno.  I"ve never been there, but ajmitch is always whining about so ..
[14:29] <persia> I've sent lots of packets there : it's not only limited, but high-latency and congested.
[14:29] <ScottK> stefanlsd: I just had the need to deal with dpkg-gensymbols.  Your wiki page was very helpful.  Thank you for putting that together.
[14:31] <stefanlsd> ScottK: aah. great!  hope it was somewhat accurate. will propose to dholbach that it be moved to Motu Recipes or similair
[14:32] <ScottK> I'll find out after sistpoty|work gives the package a once over.
[14:33] <stefanlsd> i asked sistpoty and slangasek - and they did a brief overview and said it looked ok..
[14:34] <persia> stefanlsd, I'm getting prompted by debconf for the MySQL password.
[14:37] <stefanlsd> persia: aah. kk. thanks. so its local to my pbuilder. sigh
[14:38] <persia> stefanlsd, It might also be pbuilder itself.
[14:38] <stefanlsd> i wonder if this warrants tring out sbuild
[14:42] <stefanlsd> persia: aah. ok. got it.  its in .pbuilderrc
[14:43] <stefanlsd> persia: export DEBIAN_FRONTEND="readline"   - which now prompts in readline, and i assume  "dialog" will use dialog
[14:43] <persia> Should.
[14:43] <stefanlsd> yeah, it does :)
[14:44] <stefanlsd> persia: thanks for helping me test!
[14:45] <persia> stefanlsd, Thanks for chasing the issue.
[14:45] <ScottK> sistpoty|work, TheMuso, DktrKranz, and the absent norsetto: Release Team meeting in ~ an hour.  Anything I should bring up?
[14:46] <stefanlsd> heading home, cya guys later :)
[14:46] <ScottK> ^^^ Applies to anyone else too.
[14:47] <persia> ScottK, -rt is just undergoing final testing, and is expected to upload tomorrow (unless someone objects).  I'm not sure if that's worth a mention.
[14:47] <ScottK> persia: You mean the -rt kernel?  If so there's an outstanding action from the last meeting on the topic.
[14:48] <persia> ScottK, Indeed there is.
[14:49] <persia> On the other hand, I do want to wait for both DktrKranz and TheMuso to complete any testing they want to do as well.
[14:50] <ScottK> I'll toss it in with a tentative 'tomorrow'.
[14:50] <persia> Mind you, if pgraner mentions it, there's no need.
[14:51] <ScottK> Universe comes after Kernel, so it'll be clear.
[14:52] <RainCT> (Is anyone here subscribed to the mod_python devel list?)
[15:40] <bddebian> Heya gang
[15:41] <NCommander> StevenK, still around?
[15:41]  * NCommander is back from work for the moment
[15:42] <StevenK> NCommander: Barely
[15:42] <StevenK> NCommander: Did that test work?
[15:42] <NCommander> StevenK, yes
[15:42] <StevenK> NCommander: Excellent.
[15:42] <NCommander> StevenK, I just need to fix the descriptions, and the patch can land
[15:43] <StevenK> NCommander: We pretty much had to pre-empt you, sorry
[15:43] <NCommander> StevenK, huh?
[15:43] <NCommander> StevenK, you committed my in-progress patch?
[15:45] <NCommander> StevenK, well, its not a big deal, the control files can easily be changed after the fact
[15:45] <NCommander> StevenK, what was the rush?
[15:45]  * persia suspects UTC+11
[15:45] <StevenK> NCommander: It's 1:45am, and we'd like to fix the kernel
[15:45] <NCommander> StevenK, its been broken for the rest of the cycle, why couldn't it wait a few more hours ;-)
[15:46] <persia> NCommander, Actually, no, the binaries have only been broken for ~12 hours.
[15:46] <NCommander> Oh?
[15:46] <persia> The source was broken, but it accidentally worked.
[15:46] <NCommander> o_o;
[15:46] <StevenK> NCommander: Because 1) It's been working with -3, and 2) Due to other circumstances, -mid is unable to be installed due to the -di binaries being removed
[15:46] <NCommander> Ok, that makes sense
[15:47] <persia> So everything needs to be in tip-top shape for the daily image build at ~ 2:30 UTC+1
[15:50] <NCommander> persia, the patch hasn't been committed
[15:50]  * NCommander notes there is a minor typoish issue with the control description, but that can be changed without breaking the world
[15:54] <StevenK> There is?
[15:55] <StevenK> NCommander: Move the discussion to -devel, so amitk can join in?
[15:55] <NCommander> StevenK, the description issue you noted
[15:56] <StevenK> NCommander: amitk and I already fixed that
[15:56] <NCommander> StevenK, score :-)
[16:22] <sistpoty|work> ScottK: I'll review the package once I'm home from work (probably at ~19 UTC), ok?
[16:23] <ScottK> sistpoty|work: Yes.  That'd be great.  I'm going to give the Debian maintainer until tomorrow to respond in any case.
[16:24] <sistpoty|work> ok
[16:33] <slytherin> any idea how long does it take for Debian developers to respond to a RFS request?
[16:34] <ScottK> slytherin: Somewhere between one hour and never.
[16:35] <maestrolinux> http://s2.ar.bitefight.org/c.php?uid=19732
[16:35] <RainCT> -.-
[16:35] <laga> idiot.
[16:36] <RainCT> laga: gmta :P
[16:36] <laga> RainCT: gmta?
[16:36] <sevenseeker> Great Minds Think Alike
[16:37] <laga> ah.
[16:42] <slytherin> ScottK: Ok. Do they usually respond for ping over IM?
[16:43] <ScottK> It varies
[16:57] <x1250> hi guys, can pbuilder be used before using debuild if no .dsc file is present (like in a new package) ?
[16:58] <persia> x1250, You want to use debuild -S to generate a source package, and pbuilder to convert the source package into a binary package.
[16:58] <x1250> persia, ok, thanks
[17:31] <ScottK> wgrant: I see you milestoned bug 250425.  Are you fixing it?
[17:33] <persia> it's 3:33 there, so it may be some time before an answer is available
[17:34] <ScottK> No rush.
[17:39]  * sistpoty|work decides to go home... cya
[17:48] <x1250> should I attempt to fix any of this? (3 lines paste)
[17:48] <x1250> E: inkscape_0.46.svn20001_source.changes: bad-distribution-in-changes-file intrepid
[17:48] <x1250> W: inkscape source: changelog-should-mention-nmu
[17:48] <x1250> W: inkscape source: source-nmu-has-incorrect-version-number 0.46.svn20001
[17:49] <persia> x1250, No.
[17:49] <x1250> persia, ok, thanks
[17:50] <persia> x1250, Actually, yes, but not by doing what lintian says.  Change the version to 0.46.svn20001-0ubuntu0+ppa1 or something.
[17:50] <persia> That should make them all go away.
[17:51] <x1250> thanks :)
[17:53] <nxvl> jcastro: ping
[17:54] <nxvl> mneptok: nice title for a talk :P
[17:55] <jcastro> nxvl: yo
[17:55] <nxvl> jcastro: is there any page where i can add more information about my talk (the title doesn't say much about what i want to talk)
[17:55] <jcastro> nxvl: probably wouldn't hurt to add a description section at the bottom or something.
[17:56] <jcastro> nxvl: I'm in the middle of something at the moment but feel free to add a section or whatever you think is appropriate
[17:56] <nxvl> jcastro: ok, thank you
[18:00] <fabrice_sp> Hi. Any MOTU to sponsor bug #284629?
[18:02] <ScottK> fabrice_sp: Isn't it uploaded already? http://launchpad.net/ubuntu/intrepid/+source/taskjuggler/2.4.1-1ubuntu3
[18:04] <fabrice_sp> ScottK: you're right. The strange thing is that the bug is not in Fix Released or Fix Commited
[18:04] <ScottK> Did you mark it in debia/changelog?
[18:05] <fabrice_sp> ok: my fault. I forgot the LP bug number in the changelog
[18:05]  * ScottK runs off. See you later.
[18:05] <fabrice_sp> exactly
[18:05] <fabrice_sp> CU
[18:36] <sevenseeker> does the Release.gpg on PPAs get periodically rebuilt, automatically?  I ask because frequently apt-get reports that file is missing (and I confirm with wget and FF)
[18:38] <directhex> no
[18:38] <directhex> it doesn't get rebuilt, or built, ever. PPAs are not signed
[18:40] <sevenseeker> ah
[18:40] <ScottK> Which, IMO, is a good reason not to use them.
[18:40] <sevenseeker> I wonder why suddenly my packages are not showing up (they did a few days ago)
[18:45] <sevenseeker> any ideas what changed, if I didn't knowingly change anything on my end?
[18:45] <sevenseeker> and is it possible to manually sign packages for a PPA, perhaps even TTW?
[18:49] <sevenseeker> hmmm, now it is suddenly working... I am confused ;)
[18:59] <fabrice_sp> james_w: about Bug #284786. I updated the bug, but basically, I tested that this extension is working at high level (preferences, shortcuts, mail copy, ...). Is it enough?
[18:59] <persia> fabrice_sp, If it installs and works with the existing tools, you're probably OK.
[19:03] <fabrice_sp> persia: ok. So it will be one less package with unmet dependencies in Intrepid :-) 65 left for amd64 (after upload by a MOTU)
[19:03] <persia> fabrice_sp, Nice work.  WIth 5 days left until freeze, you only have about 13 a day :)
[19:09] <fabrice_sp> persia: lol Most of them are linked to gambas2. Is someone working on them?
[19:11] <persia> fabrice_sp, I'm not sure.  Check bug assignments, or ask here (generally, rather than to someone specific).
[19:18] <fabrice_sp> persia: my intention was to ask globally, not just to you (some pb with Enter key). I'll check bug assigments. Thanks
[19:20] <persia> Good luck.
[19:29] <sevenseeker> I have specified EMAIL, DEBEMAIL, DEBFULLNAME, and NAME in my ~/.devscripts file, but when I run dch, it uses 'username@<fqdn>', do I need to enable something in /etc/devscripts.conf?
[19:30] <persia> sevenseeker, I believe that's a known bug.  Try putting them in .bashrc and starting a new shell.
[19:30] <slytherin> sevenseeker: Not sure if specifying it in ~/.devscripts help. But Ihave it set as environment variable.
[19:30] <persia> Personally, I just set DEBEMAIL to "NAME <email>" and it works for me.
[19:30] <persia> (althoguh I don't do this in my shell RC file)
[19:30] <sevenseeker> ok, will do
[19:30] <sevenseeker> thanks!
[19:31] <slytherin> wow, configuring vpn is so easy with network manager now.
[19:32] <mneptok> nxvl: money is a precious thing, sadly.
[19:32] <nxvl> yup
[19:33] <DktrKranz> persia, just installing -rt flavour, I'll reboot in some minutes and do some tests
[19:33] <nxvl> mneptok: btw, i'm buying a psp so we can play in our cigarrette breaks at UDS ;)
[19:34] <DktrKranz> nxvl, stop smoking ;)
[19:34] <nxvl> yeah, i probably won't :P
[19:34] <slytherin> isn't there any law in US which bans smoking in public space?
[19:35] <slytherin> public place I mean.
[19:35] <DktrKranz> get some good wine instead, it kills you better than smoking cigarettes
[19:35] <nxvl> slytherin: i don't live in the US
[19:35] <nxvl> :P
[19:35] <nxvl> i don't like wine
[19:35] <slytherin> nxvl: but UDS is going to be in US right?
[19:36] <nxvl> here are or bad or expensive
[19:36] <nxvl> slytherin: yes, but they have smoking areas everywhere
[19:36] <nxvl> slytherin: you can't smoke outside them
[19:36] <nxvl> slytherin: but you can around them
[19:36] <slytherin> hmm, that is fine then. unless you carry the smell with you everywhere.
[19:38] <nxvl> you do, but is not as bad as someone smoking on your side
[19:39] <slytherin> well, I do get headache with even the smell. But then probably it is just me.
[19:41] <mneptok> nxvl: AFAIK, no UDS for me.
[19:42] <cody-somerville> slytherin, No, I'm allergic as well
[19:43]  * slytherin adds 'no smoking banners' to his plan for UDS in India. :-P
[19:44] <zul> i wouldnt mind going to india
[19:45] <slytherin> zul: wow, that makes 3 supporters. :-)
[19:46] <nxvl> slytherin: 4!
[19:46] <nxvl> i will still try to make UDS in Peru
[19:46] <slytherin> :-)
[19:46] <nxvl> so i don't need to take a plane and you all get the long trip
[19:46] <nxvl> :D
[19:46] <nxvl> mneptok: :(
[19:47] <zul> nxvl: no thats ok
[19:48] <nxvl> zul: south america is cool
[19:48] <zul> nxvl: easy access to drugs ;)
[19:48] <nxvl> heh
[19:48] <nxvl> that too
[19:48] <nxvl> and cheap
[19:51] <directhex> isle of man!
[19:55] <iulian> Scotland!
[20:06] <fabrice_sp> One question about gambas2: I miss gambas2-runtime from repository for amd64 (no package exist), but i've just comiled the package in a pbuilder environment. How can I see the build of gambas2 package?
[20:06] <fabrice_sp> s/comiled/compiled/
[20:07] <fabrice_sp> (the official one, I mean)
[20:07] <persia> There's a link from https://launchpad.net/ubuntu/+source/gambas
[20:09] <fabrice_sp> persia: This link is for gambas, not for gambas2 ;-)  In the web page for gambas2-runtime (https://launchpad.net/ubuntu/intrepid/+package/gambas2-runtime), there is no link for amd64
[20:10] <persia> fabrice_sp, Check the source : perhaps it's not compiled for amd64.
[20:11] <fabrice_sp> persia: will do. Thanks
[20:12] <persia> fabrice_sp, It's commented out in P-a-s.  Check the changelog : as it's blocked on alpha, ia64, amd64, and ppc64, I suspect there's some 64-bit issue involved.
[20:12] <persia> (cf. http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.776&root=dak&view=markup)
[20:14] <fabrice_sp> persia: you're right. From the link you sent me: # ANAIS - no 64-bit support until gambas3
[20:16] <persia> fabrice_sp, That drops a bunch off the list then :)
[20:17] <fabrice_sp> Yes! :-)
[20:18] <fabrice_sp> Anyway, as it compiled successfully, I'll check if I'm able to run it :-)
[20:30] <fabrice_sp> Hehehe: gambas2 is working on amd64 (just ran several examples), so how do I request gambas2 to be build also for amd64?
[20:35] <persia> fabrice_sp, Check the upstream changelog *carefully* to make sure something changes related to 64-bits.
[20:36] <fabrice_sp> persia: in February, the version 2.1.0 became 64bit aware, and there are several fixes on 64bits problems until June. I think that archive is not up-to-date because of first version of gambas2 not being 64bit compatible
[20:37] <persia> Hrm.  2.1.0-1 seems to claim to be 64-bit compatible, but it reports it closes Debian bug #464403, which is confusing.  Is this just a bad changelog entry?
[20:38] <persia> fabrice_sp, Looks like the last gambas related change to P-a-s was r1.680 in May 2007, so I think you're right.
[20:39] <fabrice_sp> yes: it's not clear, but in the upstream changelog, it's quite clear that it's 64 bit compatible
[20:39] <fabrice_sp> * NEW: 64 bits port.
[20:39] <fabrice_sp> and in later version, you'll find fix for problems with 64 bits lib not in lib64
[20:40] <homy> Hello, I have a question about debian packages:
[20:41] <persia> homy, Which one?
[20:41] <homy> How can I make my package associate the files "*.ext" with its program on installation?
[20:41] <homy> I mean, something like automatically adding a menu entry in Applications, just with file type associations.
[20:42] <persia> homy, Read the freedesktop.org spec on .desktop files, especially the section about Mime-Type: and update your .desktop file.
[20:43] <homy> persia: but my file type is not a mime-type, it is a normal textfile with the mime type "text/plain", its just the extension that distinguishes it.
[20:44] <persia> homy, Well, then you've a bit of an issue.  You could define text/x-my-special-app, perhaps?
[20:45] <homy> persia: I don't think that's necessary. It's just a small game with the corresponding level files. Can't I just associate files with programs according to the file extensions?
[20:45] <persia> No.
[20:45] <homy> thats bad.
[20:46] <persia> Defining a Mime type is easy, and it then works with *all* the tools smoothly.  It's how we differentiate files.
[20:48] <homy> persia: how does nautilus now which file has which mimetype? I mean, my level files are normal text files, they don't have a special header, so how should nautilus be able to find the correct mimetype?
[20:49] <persia> You can use the extension as one of the ways to hint the mime type in the mime type definition.
[20:50] <homy> persia: so it comes back to looking at the extension, I just have to define a new mime-type in order for that to work.
[20:51] <homy> what does the application "file" do then? Does it determine the mime type or does it only look at the content of the file?
[20:52] <persia> homy, You've two steps : first define an experimental Mime Type for your savegame files, then create a .desktop file that says that your game is the tool to be used to open these files.
[20:52] <homy> persia: ok
[20:52] <persia> File uses the magic number system to identify the type of the file, which may or may not be related to the Mime Type.
[20:53] <persia> (the magic number system used to be mit-magic-number, and predates MIME by several years)
[20:53] <homy> persia: so if I defined a new mime type for my level files ending in ".ext", "file" would still determine the level files as "text/plain" and not "text/x-mylevelfile"?
[20:56] <persia> homy, file will probably call them "ASCII text".  The type defined by the magic number has only a loose relationship to the Mime Type (although the magic number can be used as one of the matching factors when defining a Mime Type).
[20:57] <homy> persia: ok. How do I add a new mime type? Can you give me a link or something? I can't find anything with a search engine
[20:58] <homy> ok, I think I did find something. Is http://www.freedesktop.org/wiki/Specifications/AddingMIMETutor?action=show&redirect=Standards%2FAddingMIMETutor correct?
[20:59] <persia> Yep.  That'd be the spec you want.
[21:03] <homy> persia: do I have to add "update-mime-database" to the postinst script in order for the mime type to be recognized after installation?
[21:04] <homy> and similarly also in the postrm script in order for the mime type to be forgotten after deinstalltion?
[21:05] <persia> If you're using debhelper, just add dh_desktop in debian/rules to take care of that for you.
[21:05] <persia> homy, You probably also want to read http://www.debian.org/doc/packaging-manuals/mime-policy/
[21:06] <homy> In that link it says "update-mime", in the freedesktop spec it says "update-mime-database". Both commands exist on my install. Which is correct?
[21:07] <persia> Both.  They update different MIME databases (yes this is confusing)
[21:07] <homy> so I have to run both. - or let dh_desktop run both.
[21:07] <homy> In what target do I put dh_desktop in rules?
[21:09] <persia> I usually put it in binary-arch I think.
[21:10] <persia> I may be misremembering.
[21:10] <persia> Hmm.  dh_desktop calls update-desktop-database actually, but I think that calls update-mime-database or something.
[21:11] <persia> There's also dh_installmime which would take care of the update-mime bit.
[21:13] <persia> Anyone around for the MOTU Meeting?  I think it's on, but there's no traffic in -meeting.
[21:15] <homy> persia: ok, so I need only need dh_desktop.
[21:15] <homy> Thanks for your help.
[21:15] <persia> homy, No, you want both dh_desktop and dh_installmime.  Good luck.
[21:16] <homy> thanks.
[21:17] <homy> persia: so I don't have to touch postinst and postrm, right?
[21:17] <persia> homy, Not if you let debhelper do it for you.
[21:18] <ivoks> lol
[21:18] <persia> (also known as the easy way)
[21:18] <ivoks> i've actually found a job offering
[21:18] <ivoks> request: good knowledge of ubuntu server
[21:18] <ivoks> uf... wrong channel :)
[21:18] <persia> ivoks, Neat!
[21:18] <persia> Well, it's nifty here anyway, although there is probably more likely to generate an successful application :)
[21:19] <ivoks> :)
[21:19] <ivoks> bye :)
[21:46] <wgrant> ScottK: I was going to, but haven't ended up having time.
[21:52] <jrib> python-webkitgtk is unusable.  svn fails to build as well, but I've patched that and am about to submit the patch upstream.  At this point, can I do anything to get a working python-webkitgtk into intrepid before it is released?
[21:54] <wgrant> jrib: If it's completely broken at the moment, there is a good chance a patch would be accepted to fix it.
[21:54] <persia> jrib, Document the unusablity in a bug.  Attach the smallest possible patch to make it actually do something.  Subscribe the sponsors.  Maybe say something here.
[21:54] <wgrant> As there's not much regression potential from something not working.
[21:54] <jrib> wgrant: good point.  wgrant, persia: thanks
[21:56] <persia> wgrant, My only fear with big patches to make things work is that they may break in other ways: I'd generally prefer to have something stable with a specific known problem that could be addressed via SRU once a solution is found than something shiny for which we don't know the bugs, and may end up with odd unexpected issues.
[21:58] <Laney> Is there anyone from motu-sru around? Can I poke you to bug #280129?
[22:02] <Laney> Also motu-council people: Can I request that your minutes actually include summaries of the discussions? They're largely pointless as just an agenda.
[22:11] <persia> Laney, Compare to the minutes of the non-public deliberations of any of the other councils.  Which would you prefer?
[22:11] <Laney> persia: I don't know what other councils do, I was just suggesting that more information would be welcome
[22:12] <persia> Laney, Most of the councils have a private mailing list and a public IRC meeting.  The minutes and logs of the IRC meetings are available.  The contents of the mailing lists are not.
[22:14] <persia> To date, MOTU Council has worked the other way, under the assumption that it's better that any issues raised are seen, and all decisions are taken on the mailing list.  The minutes of the weekly meetings are mostly just to inform what things are being discussed so people can complain if there is some issue they want discussed that was not dicsussed.
[22:14] <Laney> persia: Bullet point 2 on https://wiki.ubuntu.com/MOTU/Council
[22:14] <Laney> ;)
[22:15] <persia> Laney, Yes.  The actions and processes are.  The actual content of some discussion is not.  Would you rather you weren't informed which discussions were occuring (as happens for other councils)
[22:18] <Laney> Well knowing that a discussion takes place adds some information, but I'm not sure that it's enough to be called transparent, and I'm not sure that we should be influenced by precedent set by other councils. I'd just like to see a short summary of what was discussed for each point - I'm in no way suggesting that you shouldn't be able to redact information if you feel doing so is appropriate.
[22:19] <persia> Hrm.  Maybe.  Current practice is that no decision can be taken in a private IRC meeting : it's just a discussion forum to avoid conflict in other actions.
[22:19] <persia> Bascially, it grew out of previous /privmsgs and private email that happened between council members about various things.
[22:20] <persia> I thought this was more open, and actually prefer to post unredacted agendas than redacted detailed minutes.
[22:21] <persia> If there's any actual decision or consensus, it will certainly be shared, but based on bullet points 3 & 4, the MOTU meeting that happened 80 minutes ago (with zero attendance) has a lot more impact on MOTU policy than any deliberations of MC.
[22:22] <emgent> heya
[22:22] <ajmitch> persia: was the MOTU meeting announced?
[22:22] <ScottK> wgrant: Then please either unmilestone the bug (later) or find the time ....
[22:22] <persia> So, if there's something you want to see, or change, or discuss: please bring it to a MOTU Meeting.  That's the decision forum.
[22:22] <persia> ajmitch, It was in the topic.  I don't think anyone sent any email.
[22:22] <wgrant> ScottK: Doing so.
[22:23] <ajmitch> right, the topic which would be too long to fit on my screen
[22:23] <ajmitch> and lurkers like me don't see it getting changed
[22:23] <ScottK> wgrant: It also got mentioned at the release meeting that there were a number of unfixed security bugs in Universe.  You wouldn't happen to have a list, would you?
[22:23] <persia> Next one is 31st October, 4:00 UTC.  I might send an email about it tomorrow if nobody else does, as the lack of attendance or agendas at MOTU meetings combined with the long and fractured discussions on the mailing lists are annoying me.
[22:24]  * ajmitch won't attend that one
[22:24] <wgrant> ScottK: We have hundreds... take your pick. There is a fairly easy way to generate a nice HTML list from ubuntu-cve-tracker. I'll whip one up later.
[22:24] <persia> too late in the day?
[22:24] <jdong> note to self: don't unload the usbhid modules to reset a quirky mouse
[22:24] <ajmitch> persia: 5pm on a friday? :)
[22:24] <ScottK> wgrant: Please and then send mail to the Ubuntu ML to get people focused.  Just the Intrepid ones.
[22:25] <persia> ajmitch, Clearly the perfect time for a meeting :)
[22:25] <wgrant> jdong: I do that all the time... but I have an && sudo modprobe afterwards.
[22:25] <jdong> wgrant: yea yeah minor details....
[22:26] <ajmitch> persia: not at my workplace :)
[22:27] <Laney> 5pm Friday is clearly pub time!
[22:28] <persia> ajmitch, yeah, well.  I live in the land of 過労死
[22:29] <Laney> I think announcements 7 and 1 day before MOTU meetings could be useful
[22:29] <Laney> 7 days - add your agenda items now
[22:29] <Laney> 1 day - reminder that it's happening
[22:31] <persia> That was the guideline, but the assigned person at one meeting didn't do that, and there haven't been many useful meetings since, and nobody has been so assigned.
[22:31] <persia> Like I said, this is starting to annoy me, so I may well do that this time.
[22:31] <wgrant> How long is it since we've had a meeting?
[22:32] <persia> A useful meeting?
[22:32] <wgrant> A meeting where there were attendees and an agenda.
[22:33] <persia> Last useful meeting was the one where we decided to use the *still not documented* decision process involving sending stuff to the mailing lsits.
[22:53]  * ScottK hides
[22:53] <persia> ScottK, Don't worry about it.  I'm planning to relieve you of the responsibility for documenting it in about a fortnight.
[22:53] <ScottK> Kewl.
[22:53] <ScottK> Procrastination pays.
[22:54] <persia> Well, that or perhaps that which is incomplete gets cancelled.  We'll see at the meeting.
[22:54] <persia> In any case, regardless of the decision, I expect your support in getting someone else assigned to document it.
[22:55] <ScottK-laptop> persia: I confess I'd forgotten.  Shoot me a wiki link on where it goes and I'll do it right now.
[22:55] <persia> wiki.ubuntu.com/MOTU/Meeting I think.
[22:55]  * ScottK-laptop looks
[22:56] <persia> Of course, I'm not that excited about you doing it now, as it adds to the number of emails I need to both read and write in the next couple weeks.
[22:56] <ScottK-laptop> ;-)
[22:56] <persia> So, if you feel like putting it off another couple weeks, feel free :)
[22:56] <ScottK-laptop> I'll blame wiki editing with Konqueror (and basically any non-gecko browser) being broken for a month.
[22:57] <persia> That's not a good excuse.  What about the couple months before that?
[22:57] <persia> But like I said, it shouldn't matter : the current state of things is *far* too broken to continue.
[22:58] <persia> Not that I want lots of change, but rather I'd like not to have people expecting any meaning out of MC meetings.
[22:59] <ScottK-laptop> Right, well not having the process written down certainly hasn't been helpful.
[23:00] <ScottK-laptop> How about MOTU/Policy (it's bigger than meetings) <-- Persia
[23:00] <ScottK-laptop> Or persia ^^^ on the off chance that's case sensitive for you...
[23:01] <persia> Nah.  I've a fairly flexible alert system, although annoyingly the audibility broke.
[23:02] <persia> Doesn't really matter where you put it.  Just make sure it's *really* easy to find from MOTU/Meetings, and be prepared to adjust/change it in two weeks.
[23:02] <persia> Since we've not had a useful MOTU Meeting since it was introduced, I am very suspicious of it being healthy.
[23:03] <persia> Not that I think it's bad to solicit more opinions, just that it only got used once, and badly at that.
[23:03] <persia>  And the final decision ended up being made the same way it was made before, except it took twice as long.
[23:04] <ScottK-laptop> Except the one that took twice as long, I don't think we've had any decisions wanting.
[23:06] <persia> I suppose, but there's surely been things worth discussing.
[23:06] <persia> Most of the "decisions" of MOTU Meetings were about relatively insignficant stuff, or planning/coordination things.
[23:06] <persia> None of these have been happening, which leaves us where we are now.  There are other factors, of course.  I don't blame this all on the lack of meetings.
[23:22] <RainCT> persia: mail reminders, mail reminders, mail reminders :)
[23:35] <ScottK> persia: Documented and on the agenda for the next meeting.
[23:37] <RainCT> good night