[12:14] <superm1> exactly
[12:14] <superm1> that was copied from the gutsy ubuntu seed
[12:14] <superm1> but its not used at all
[12:14] <superm1> i guess it could be removed since its not used
[12:20] <Riddell> superm1: but why don't you use it?
[12:20] <Riddell> superm1: what are you trying to create here?  is this only for a live CD?
[12:20] <superm1> Riddell, because we dont have a desktop target at all.  The boxes are supposed to be set up like appliances
[12:21] <superm1> the live package is just for the live disk, the standalone is used after install is completed
[12:22] <Riddell> install of what?
[12:22] <superm1> there is an ubiquity derived installer in live mode
[12:22] <superm1> that copies everything over and preconfigures the appliance
[12:24] <Riddell> superm1: so run me through how you'd set up mythbuntu on a box
[12:26] <superm1> Riddell, okay, so you'd pop in this disk.  If you've got an existing box setup, and this is adding to the network, you have the option to either add this as a "live" frontend or install as a standalone.  If it is ran as a live frontend, all the settings you choose are copied to a flash drive.  If you choose to install, you open up the installer.  Youre provided with a list of htings to change and modify.  You choose to your liking and its i
[12:26] <superm1> nstalled like a standard ubuntu install
[12:26] <superm1> once you reboot, you're ideally all set up and ready to go
[12:26] <superm1> and can go right into media library, watch tv, etc
[12:26] <superm1> so after the install finishes, it removes mythbuntu-live
[12:26] <superm1> and any other unnecessary packages
[12:27] <superm1> but mythbuntu-standalone sticks around for similar purposes as ubuntu-desktop between releases
[12:29] <Riddell> so mythbuntu-live is unnecessary for the installed mythbuntu box?
[12:29] <superm1> correct
[12:30] <superm1> but it simplifies the current build process
[12:30] <superm1> and the uninstallation of unnecessary items
[12:30] <Riddell> but it has all the myth stuff in it
[12:30] <Riddell> there's hardly anything in standard
[12:31] <superm1> because so many things can be customized during the install
[12:31] <superm1> and shouldn't be present on every box
[12:32] <superm1> during install the user gets to choose if the box will be a frontend / slave backend /master backend /customizes plugins/ customizes services
[12:33] <Riddell> what do you mean by a "live" frontend?
[12:33] <superm1> live in the sense, that you dont need a hard drive.  You cna boot off the disk, and load your settings for connecting to another box from a flash drive
[12:34] <superm1> or choose them on the fly
[12:35] <Riddell> man, this is going to complicate my SeedManagement diagram :)
[12:35] <Riddell> is standard the same as ubuntu-standard?
[12:36] <superm1> yes
[12:36] <Riddell> oh, wait, it's standalone
[12:36] <superm1> the standalone isn't however
[12:37] <RainCT> does the debian/menu file accept PNGs? (can't remember it now)
[12:37] <Riddell> superm1: so why not make standalone the desktop seed?
[12:38] <superm1> well we could do that, but then would have to deal with inheriting all the stuff from the standard ubuntu desktop seed right?
[12:39] <Riddell> presumably you're expecting to make CDs out of this in the same way as ubuntu desktop CDs are with the live filesystem being made from desktop+live (except in your case it's now standalone+live)
[12:40] <superm1> well the current way that we are making disks isn't the same as the ubuntu desktop CDs are made
[12:40] <superm1> its a custom script that i wrote
[12:41] <superm1> i wasn't finding much about the way desktop CDs were made
[12:41] <Riddell> no, that isn't released yet, it should be sometime before gutsy comes out
[12:42] <superm1> hence why I couldnt find it then :)
[12:42] <superm1> in any which case, i can point you at our build script should you be curious how we are doing that too
[12:45] <Riddell> I think renaming desktop to standalone is a bad idea, it just confuses that it does the same thing, and I wouldn't worry too much about merging being a hassle, I merge ubuntu desktop changes in kubuntu desktop seed all the time and it's not a problem
[12:45] <Riddell> otherwise, seems fine to me, although cjwatson is the authority when it comes to seeds
[12:46] <Riddell> superm1: your script takes an existing CD and remasters the live filesystem?
[12:46] <superm1> Riddell, no.
[12:46] <superm1> it debootstraps in
[12:46] <superm1> and then creates a cd from scratch
[12:46] <Riddell> ah, clever :)
[12:47] <superm1> only unfortunate side effect is that squashfs-tools ends up in the CD image right now
[12:47] <superm1> i'm assuming something similar is done for the ubuntu desktop CDs however?
[12:47] <geser> RainCT: iirc no, as not all window managers support it. I hope the menu policy mentions it.
[12:47] <Riddell> yes
[12:48] <superm1> Riddell, so how do I avoid getting all of the ubuntu-desktop items in my desktop seed then when it uses the normal gutsy seed to base from in [gutsy]  from update.cfg?
[12:49] <superm1> Riddell, and if your curious to see what I do: http://codebrowse.launchpad.net/~mythbuntu/mythbuntu/mythbuntu-livedisk/annotate/supermario%40portablemario-20070731074308-8vd91mtlqhc63a2u?file_id=mythbuntu_install.sh-20070730021708-mgcieyteypjaasi6-4
[12:49] <Riddell> well, remove them from your desktop seed
[12:49] <superm1> Ok.
[12:52] <Riddell> superm1: what's the point of the mythbuntu-live package?
[12:53] <superm1> Riddell, easy way to modify what's installed in builds without having to modify the build script
[12:54] <Riddell> ok, the other seeds don't have it so it's a bit a-typical, but then you're not using the same CD build script, so it's fair enough
[12:56] <superm1> Riddell, given what i'm currently doing here for the builds, will it be a less painful transition over to doing the builds the way the standard desktop cds are built when that procedure is released?
[12:57] <Riddell> will what?
[12:58] <superm1> moving away from this build script to the method used to build ubuntu desktop disks
[12:58] <Riddell> renaming standalone back to desktop would be I imagine yes
[12:59] <Riddell> if that's what you're talking about?
[12:59] <superm1> well you had said that the process used to build ubuntu desktop cds will be made clearer by gutsy release
[12:59] <superm1> so i'd ideally switch things over to be built that way
[01:01] <Riddell> sure, this seems the way to go
[01:02] <superm1> ok then i'll switch it over
[01:03] <superm1> Riddell, should I still push this through the standard revu procedure given that not all of -motu is confident on seed functionality?
[01:03] <Riddell> superm1: probably not, run it by cjwatson instead
[01:04] <superm1> Ok.  i'll do that then
[01:04] <superm1> thanks for your help Riddell :)
[01:04] <Riddell> no problem, it's been interesting
[01:07] <Riddell> let me know if you need me to upload it, once cjwatson has seen it
[01:08] <superm1> okay will do
[01:10] <RainCT> Good night all
[02:30] <bddebian> Heya gang
[02:31] <crimsun> hey, it's the other guy who isn't online much!
[02:31] <bddebian> crimsun: !!
[02:31] <crimsun> how's life?
[02:31] <bddebian> Well I'm hoping to come back
[02:31] <crimsun> excellent.
[02:31] <bddebian> Has been busy as hell but slowing down.  You?
[02:32] <crimsun> getting busier here, will be offline for an extended period shortly.
[02:32] <bddebian> Doh :-(
[02:32] <crimsun> don't worry, there are still plenty of packages awaiting your touch :-)
[02:33] <bddebian> Heh
[02:43] <RAOF> Like xserver-xgl!
[02:45] <crimsun> and alsa-*!
[03:01] <zul__> isnt TheMuso doing alsa ;)
[03:03] <ajmitch> hello crimsun, zul_______
[03:04] <zul__> hey ajmitch how goes it?
[03:04] <ajmitch> alright
[03:10] <ScottK> Good evening everyone.
[03:11] <ajmitch> hello ScottK 
[03:11] <ScottK> Seems like you aren't the only one grumpy about tracker.
[03:12] <Hobbsee> hiya
[03:12] <ScottK> Hi there.
[03:12] <RAOF> Yay!  I managed to log a trackerd segfault.
[03:14] <RAOF> Oh.  That's a boring log.  Darn.  Hope the backtrace is interesting at least.
[03:16] <ajmitch> ScottK: me, grumpy?
[03:16] <ScottK> Wait, no...
[03:16] <ScottK> Maybe it was bitter.
[03:16] <ajmitch> yeah, I can do bitter
[03:16] <zul> sarcastic even?
[03:17] <ajmitch> nah
[03:17] <Hobbsee> hiya ajmitch 
[03:17] <zul> hey Hobbsee 
[03:18] <Hobbsee> hiya zul 
[03:20] <bddebian> Heya ScottK
[03:20] <TheMuso> Greetings all.
[03:20] <ScottK> High there bddebian.
[03:21] <bddebian> Heya TheMuso
[03:25] <bryce> I've got a package (displayconfig-gtk) in Section: admin, and am getting this error when doing pbuilder:  Copying source file
[03:25] <bryce>     -> copying [displayconfig-gtk_0.2+20070731ubuntu2_source.changes] 
[03:25] <bryce>     -> copying [./admin] 
[03:25] <bryce> cp: cannot stat `./admin': No such file or directory
[03:25] <bryce>  -> Aborting with an error
[03:25] <bryce> anyone know offhand what this means?
[03:28] <Hobbsee> bryce: at the end presumably?
[03:28] <bryce> yup
[03:29] <Hobbsee> bryce: got the source that you can dump somewhere?
[03:29] <RAOF> Maybe the changes file points to it?
[03:29] <bryce> no idea.  If I change it to Section: gnome, then it complains about cannot stat `./gnome': ...
[03:29] <StevenK> Neat!
[03:29] <RAOF> That's pretty cool, yeah.
[03:29] <StevenK> bryce: Can you pastebin the debian/rules file?
[03:30] <bryce> sure
[03:30] <bryce> this is in the *source.changes:
[03:30] <bryce> Files:
[03:30] <bryce>  f20f849c1f2e9c038e644c94293340fd 671 admin optional displayconfig-gtk_0.2+20
[03:30] <bryce> 070731ubuntu2.dsc
[03:30] <bryce>  58b085ef5924d3f8b738ed273eb7f675 77649 admin optional displayconfig-gtk_0.2+
[03:30] <bryce> 20070731ubuntu2.tar.gz
[03:30] <bddebian> RAOF: Where's your xserver-xgl bzr branch?
[03:30] <bryce> http://pastebin.ca/649354
[03:31] <RAOF> bddebian: https://code.launchpad.net/~raof/xserver-xgl/ubuntu-raof
[03:31] <Hobbsee> bryce: for a start, were you intending to build that natively?
[03:31] <RAOF> It's also linked to a bug in the u-u-s queue.
[03:32] <bryce> Hobbsee: "natively"?  I was attempting to build it in a pbuilder gutsy environment on a feisty system
[03:32] <Hobbsee> bryce: no .diff.gz, and no orig.tar.gz
[03:33] <bryce> Hobbsee: I'm attempting to build from displayconfig-gtk's latest bzr checkout
[03:33] <bryce> (plus some changes of my own)
[03:34] <bryce> ok, anyway, nevermind, I was just hoping this would be an obvious error message to someone.  I'll experiment a bit more and sort it out.  thanks
[03:36] <RAOF> bddebian: bzr smart-server is coming Real Soon Now(tm) to launchpad, that makes it quite a lot faster.
[03:36] <bddebian> *cough*
[03:37] <ScottK> Good thing the LP devs have a good reputation for being able to deliver speedy/responsive <<<<<<<< nevermind.

[03:37] <bddebian> heh
[03:38] <Fujitsu> RAOF: It's already there...
[03:39] <RAOF> But not advertised, because it thrashes I/O on launchpad.
[03:39] <Fujitsu> Aha.
[03:39] <bddebian> Hmm, I wonder if I start a build of glibc on GNU/Hurd if it would actually finish before bzr
[03:39] <Hobbsee> RAOF: i wonder how one uses it, then
[03:40] <RAOF> Apparently it'll be fixed + advertised in bzr 0.20 :(.
[03:40] <Fujitsu> Wasn't 0.18 just released?
[03:41] <Hobbsee> RAOF: right, i'll pull other strings then :)
[03:41] <StevenK>        bzr |     0.18-1 |         gutsy | source, all
[03:41] <RAOF> Not very long ago, yeah.  Apparently it missed 0.19 because I gave all the Sydney bzr hackers the flu.
[03:42] <ajmitch> bad bad RAOF 
[03:43] <bddebian> heh
[03:43] <ajmitch> bryce: you are running pbuilder build against the .dsc, right?
[03:43] <bddebian> This is ridiculous
[03:44] <RAOF> bddebian: Some of the slowness you're seeing is my fault; I shouldv'e excluded the .git directory from the initial import.
[03:44] <bryce> ajmitch: thx
[03:44] <ajmitch> bryce: easy mistake to make :)
[03:45] <bddebian> d00d, I've dist-upgraded my hurd box and pulled the glibc source so far and this thing isn't even 1/2 way done yet :-)
[03:45] <ajmitch> bddebian: checking out his xgl branch?
[03:45] <bddebian> Was trying to but about to stop it :-)
[03:45] <ajmitch> took me about 2 hours to check it out
[03:45] <bddebian> chirst
[03:46] <RAOF> Gah!  Smart server is so much faster!  Uuurgh!
[03:47] <bddebian> Oh my it finished
[03:47] <bddebian> Do I have to do that stupid get-orig-source or whatever also??
[03:48] <RAOF> bddebian: No.  "bzr bd --split"
[03:48] <bddebian> huh?
[03:48] <RAOF> That's how to build it (easily).
[03:49] <bddebian> what the heck is bzr bd --split?
[03:49] <RAOF> bd is the bzr-builddeb plugin, --split tells it to make an orig.tar.gz from the non-debian part of the working dir.
[03:50] <bddebian> bzr: ERROR: unknown command "bd"
[03:50] <RAOF> Install bzr-builddeb?
[03:50] <ajmitch> not really nice to make an orig.tar.gz with that, but oh well
[03:51] <RAOF> ajmitch: It's just a git snapshot.  Is it really worth making a separate tarball?
[03:51] <RAOF> ajmitch: I can if it's important.
[03:51] <RAOF> If there *was* a release, I certainly wouldn't be doing it.
[03:53] <ScottK> bddebian: We're just old and don't understand.
[03:53] <RAOF> It offers a more fine-grained history than changelog?  Makes it easier to collaborate on maintenance?
[03:54] <bddebian> ScottK: Apparently :_)
[03:54] <ScottK> Yes, but we aren't doing team maintenance on your package.
[03:54] <ScottK> You're wanting bddebian to review it.
[03:55] <ScottK> dget -x .... is so much easier.
[03:55] <ajmitch> poor bddebian 
[03:55] <bddebian> OK so that fails because I don't have nor want the build deps.  I need to build it in a pbuilder
[03:55] <RAOF> ScottK: True.  I could push it to revu if that's easier.
[03:55] <ajmitch> no you can't
[03:55] <ScottK> Ah. no.  see /topic
[03:55] <RAOF> Well, not until it's up again, of course :)
[03:55] <ajmitch> revu has left us
[03:55] <bddebian> :'-(
[03:55] <Fujitsu> REVU is some way away.
[03:55] <ScottK> How big is it?
[03:56] <Fujitsu> It's being moved into the DC, so... who know.
[03:56] <Fujitsu> *knows
[03:56] <ScottK> Oh my.
[03:56] <ajmitch> most likely not before freeze
[03:56] <ajmitch> so effectively not used before release
[03:56] <bddebian> I can see it for upstream development but I don't get it for distro changes but what do I know, I'm a moron
[03:56] <ScottK> Would have been nice to have waited until after the freeze for that then....
[03:57] <ScottK> bddebian: Do you read ubuntu-devel?
[03:57] <Fujitsu> ScottK: There was apparently a security issue on 4 loco servers, including tiber.
[03:57] <ScottK> Ah.
[03:57] <bddebian> ScottK: I get it, I don't always read it.  I have a life ya know :-)
[03:57] <ScottK> OK.
[03:57] <Fujitsu> So they're all being moved into the DC, which also means no root access except for canonical-sysadmins.
[04:00] <StevenK> Fujitsu: Where was that message? I can't see it in the archives.
[04:00] <Fujitsu> StevenK: lococontacts.
[04:01] <ScottK> bddebian: There was sort of related thread over the weekend through today on apt-get source wanting to redirect you to a vcs.  That's all.
[04:01] <bddebian> egads
[04:02] <Fujitsu> The ETA has unfortunately been revoked :(
[04:03] <ajmitch> big surprise
[04:03] <ScottK> If I can bring up a basic Ubuntu LAMP box to use in the meantime, would someone be willing to set up another instance of REVU on it?
[04:03] <ajmitch> time to use other services
[04:04] <ajmitch> and if they're alive
[04:04] <Fujitsu> At least tiber will be new hardware when it returns.
[04:04] <ScottK> I've got spare IPs and a spare box that's a bit in pieces, but I've got all the pieces.
[04:04] <ScottK> I've also got bandwidth.
[04:05] <ScottK> I had plans for it, but don't need it until next month.
[04:06] <ajmitch> so the problem is setting up an instance of REVU
[04:07] <Fujitsu> I'd first try to get a very ETA from newz2000, but he's likely not around for some hours :(
[04:08] <ajmitch> nor is setting it up at all documented
[04:08] <Fujitsu> Would there have been many changes?
[04:08] <Fujitsu> I set it up a year or so ago, it's not too hard.
[04:08] <ajmitch> some small changes
[04:08] <ScottK> REVU minus a few patches is better than no REVU at all.
[04:09] <ajmitch> only marginally so at times
[04:09] <ajmitch> at least it'd give us a chance to clear the backlog...
[04:09] <Hobbsee> we could just get rid of REVU entirely... </hopeful?
[04:09] <Fujitsu> It was last merged 3 months ago.
[04:09] <Hobbsee> we could just get rid of REVU entirely... </hopeful>
[04:09] <bddebian> heh
[04:09] <ajmitch> Hobbsee: replace it with...?
[04:09] <Hobbsee> ajmitch: no new packages to ubuntu
[04:09] <Fujitsu> ajmitch: No it wouldn't. We haven't got the data from tiber accessible until the new server appears.
[04:09] <Fujitsu> Hobbsee: That would be nice.
[04:10] <bddebian> Grr I can't get shit accomplished this evening.. Sheesh
[04:10] <ScottK> bddebian: Fix bugs?
[04:10] <ScottK> Steal packages off of mentors?
[04:11] <ajmitch> Fujitsu: that's what I mean by clearing the backlog
[04:11] <RAOF> It's probably against Debian ettequete to file a "new upstream version" bug with a debdiff to upgrade the package, right?
[04:11] <Fujitsu> ajmitch: Ah, I see.
[04:11] <ajmitch> Hobbsee: not likely to happen
[04:12] <ScottK> RAOF: I've seen it often done with a link to the .dsc for the upgraded package.
[04:13] <RAOF> ScottK: Awesome.  I'll look into that then.
[04:13] <bddebian> The uus queue actually looks pretty clean
[04:14] <ScottK> Merges then...
[04:14] <ajmitch> only because people have been all over it, frequently
[04:14] <bddebian> Where are merges these days?  mom, dad, baby, what? :-)
[04:14] <RAOF> bddebian: You could take the new upstream version of azureus off my hands, if you like!
[04:14] <bddebian> no thanks :-)
[04:15] <ScottK> bddebian: MoM or DaD as you prefer.
[04:15] <ScottK> Each has advantages.
[04:24] <ScottK> Fujitsu: Would you be willing to follow up with newz2000 about an ETA for REVU and help me get a new one up and running if it isn't soonish?
[04:24] <Fujitsu> ScottK: I poked him 20 minutes ago, but he's likely asleep or busy with something else.
[04:24] <ScottK> OK.
[04:24] <Fujitsu> He's in UTC-5, AFAIK.
[04:25] <ScottK> Hmmm
[04:25] <ScottK> Pleny early then.
[04:25] <Fujitsu> Fairly.
[04:25] <ScottK> Plenty even
[04:25] <Fujitsu> Just got a response.
[04:25] <ScottK> And ...
[04:26] <Fujitsu> elmo is working on it, with actual transfers likely starting tomorrow morning London time.
[04:27] <ScottK> ETA this weekish then?
[04:28] <Fujitsu> Probably within the next day or two.
[04:28] <Fujitsu> The hardware is all ready and stuff, just got to get the data from ServerPronto.
[04:28] <ScottK> Cool.
[04:28] <ajmitch> not nearly as bad as feared
[04:28] <Fujitsu> Fortunately.
[04:28] <ScottK> Then I guess my box can rest in peace (or pieces) for a while yet.
[04:29] <bddebian> Install GNU/Hurd on it ;-P
[04:30] <Fujitsu> Hah.
[04:30] <ScottK> No thanks.  I do eventually want it to do something.
[04:31] <bddebian> pfft
[04:32] <ajmitch> ScottK: that's easy
[04:32] <ajmitch> it'll eventually crash
[04:33] <bddebian> It's gotten much more stable actually
[04:33] <wfarr> bugger about REVU being down
[04:33] <Fujitsu> wfarr: Yeah, probably a couple of days until it's back.
[04:34] <wfarr> I'll have to find somewhere else to upload a package I need reviewed for now
[04:35] <Fujitsu> Hm, as tiber was likely compromised, all the packages on there have to be considered more tainted than usual.
[04:36] <Hobbsee> Fujitsu: might be an idea to ask everyone to reupload the packagse they're interested in.  *shrugs*
[04:36] <ajmitch> Fujitsu: yes
[04:36] <Fujitsu> Hobbsee: Yes, it is worth it.
[04:36] <ScottK> Fujitsu: Is it know when the period of vulnerability was?
[04:36] <Hobbsee> Fujitsu: exactly
[04:36] <ajmitch> however each package on there still has its corresponding .changes file that is signed
[04:36] <Fujitsu> ScottK: It was discovered on Monday, but I'm not sure if it's know.
[04:37] <ScottK> OK.
[04:37] <TheMuso> ajmitch: THey could have been resigned.
[04:37] <Fujitsu> *known
[04:37] <ajmitch> so the package source should still be able to be verified
[04:37] <Fujitsu> ajmitch: I thought of that... Unfortunate :(
[04:37] <ajmitch> TheMuso: then you'd easily be able to check that, wouldn't you?
[04:37] <Fujitsu> We can just recheck everything against the REVU keyring.
[04:37] <TheMuso> ajmitch: Yeah true that.
[04:37] <ajmitch> it's not like we really trust anything on there anyway
[04:37] <ajmitch> given that the keyring is basically wide open
[04:37] <Fujitsu> `more tainted than usual'
[04:38] <bddebian> OK so uploading is off period atm?
[04:38] <ajmitch> bddebian: no uploads to revu
[04:38] <Fujitsu> bddebian: Not to the archive.
[04:38] <bddebian> Grr
[04:38] <Hobbsee> ajmitch: hush.  we want to cut down the number of packages on there
[04:38] <TheMuso> Requires manual approval afaik.
[04:38] <Fujitsu> Hobbsee: That's what I was thinking. I hope the attacker obliterated the .changeses.
[04:39] <bddebian> Well the last one I got a message about awaiting moderator.  This one just got plain rejected
[04:39] <Hobbsee> Fujitsu: even if they didnt, we can consider them compromised
[04:39] <Fujitsu> bddebian: What was the rejection message?
[04:39] <bddebian> Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.
[04:40] <Fujitsu> bddebian: You can't upload to feisty.
[04:40] <bddebian> wtf
[04:40] <Fujitsu> Or any other pocket than PROPOSED or UPDATES of a CURRENT distrorelease.
[04:40] <bddebian> Gahh, moron
[04:41] <bddebian> This is why I hate scripts doing things for me :-)
[04:42] <ajmitch> don't mention that you use scripts to automate stuff
[04:42] <bddebian> I meant just dch -i :)
[04:42] <TheMuso> bddebian: YOu have to check that, especially if you are using feisty.
[04:43] <TheMuso> I have made that mistake once before.
[04:43] <bddebian> I know but I'm old and senile
[04:43] <ajmitch> quick, everyone lynch him!
[04:44] <bddebian> :'-(
[04:53] <ajmitch> don't be silly
[04:53] <ScottK> bddebian: Don't do that.  Then I'd have to be old and bitter here by myself again.
[04:56] <Hobbsee> ScottK: and who would you find to have 4 hour rants with?
[04:57] <bddebian> ScottK: hehe
[04:58] <ajmitch> not me
[05:00] <ScottK> IIRC it was Laserjock last time.
[05:00] <ajmitch> and look what you did to him
[05:01] <ScottK> Yeah, well at least I got through 4 hours with him without violating the CoC.
[05:01] <ScottK> I have done less well on that in far less time recently.
[05:01] <bddebian> I can't get through 5 minutes without violating the CoC :-)
[05:01] <ScottK> Yeah, but I did it on a logged IRC channel.
[05:01] <ScottK> That hurts the deniability.
[05:02] <ajmitch> nor in private, of course
[05:12] <calc> ScottK: heh
[05:12] <bddebian> Do we really need to change the Section to Multiverse for contrib packages from Debian?
[05:12] <ScottK> Which?
[05:12] <ScottK> bddebian: Why would we do that?
[05:12] <calc> crimsun: still here?
[05:12] <bddebian> Dunno apparently it was done for ivtv
[05:13] <ScottK> AFAIK that's not a valid section.
[05:25] <bddebian> Hmm, I think ivtv should be synced..
[07:25] <pedahzur> Anybody here deal with X packages? It seems this wishlist item has languished for a while.  Anyone want to tackle it? https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/102018
[07:26] <ubotu> Launchpad bug 102018 in xorg "[Needs-packaging]  lbxproxy" [Wishlist,Confirmed]  
[07:27] <Hobbsee> pedahzur: feel free to
[07:28] <pedahzur> I know...I need to learn to package things anyway, but trying to package something that is part of a larger ecosystem like X isn't really my idea of a "first time packager" task.  Guess I need to a) find a smaller package, b) find a mentor, or c) both. :)
[07:29] <pedahzur> What's the general opnion of "fixing" packages that were created with checkinstall?  If I created it that way, could I wrangle it into shape, or is the general consensus that one should start from scratch?
[07:30] <RAOF> pedahzur: It would take more effort to fix a checkinstall package than it would to package from scratch.
[07:30] <Hobbsee> pedahzur: you dont end up with a source at all, for a checkinstall package, do yoU?
[07:30] <RAOF> Anyway, checkinstall doesn't make a source package?
[07:30] <pedahzur> Hobbsee: Not sure...I think it has all the rules there, but you might not.  Never checked that because I never needed it. :)
[07:30] <Hobbsee> pedahzur: unless you like editing binary files, i'd suggest you start from scratch
[07:31] <Hobbsee> pedahzur: it doesnt really help you
[07:32] <pedahzur> OK.
[08:18] <RAOF> While I'm touching compizconfig-python, do we want to make it build for all supported python versions?
[08:18] <RAOF> Amaranth: Ping, re compizconfig-python
[08:47] <Wedhus_Liar> i need help about crossover installation
[09:11] <DarkSun88> Hi all
[09:17] <\sh> moins
[09:19] <DarkSun88> Hi \sh 
[09:56] <TheMuso> I'd be there for the next system build I would do.
[09:56] <TheMuso> I don't need a chunky card at all.
[09:56] <Yagisan> nice shiney new 8500GT - bouaght because new systems don't have agp slots anymore ...
[09:56] <Yagisan> I try 3d games development
[09:57] <RAOF> Owch, you can't even use the packaged drivers.
[09:57] <Yagisan> that was the cheapest card I could find that does SM4, and as a added bonus - fanless
[09:57] <Yagisan> RAOF, yeah - nvidia-glx-new didn't work
[09:58] <RAOF> And stable-driverless, sadly.
[09:59] <Yagisan> what really sucks
[09:59] <Yagisan> my old hardware isn't supported anymore
[10:00] <Yagisan> (I really need to get a spellcheck for xchat)
[10:00] <Yagisan> it still does 2d
[10:00] <Yagisan> but no 3d since xfree86 3.3
[10:00] <TheMuso> Yagisan: Wow, talk about a regression.
[10:01] <RAOF> That card never really did 3d anyway, though, right?
[10:01] <Yagisan> TheMuso, nobody cares about it anymore
[10:01] <Yagisan> it did a decent amount of 3d
[10:01] <Yagisan> not full T&L
[10:01] <TheMuso> c
[10:01] <RAOF> Oh, really
[10:01] <TheMuso> ugh
[10:01] <Yagisan> but certaily helped with texturing etc
[10:01] <RAOF> One of my friends had one of those cards, and we tried to run a game.
[10:02] <RAOF> Not so much with the 3d, then.
[10:02] <TheMuso> And then it was so cool and new for it all to be on one card. :)
[10:02] <Yagisan> I bought that card for my then 486
[10:02] <Yagisan> it had a whopping 4MB of EDO ram
[10:03] <RAOF> Yeah, that's right.  I think the one I knew was in a pentium 133
[10:03] <Yagisan> 25% of what my 486 had
[10:03] <RAOF> That 486 had a lot of ram!
[10:04] <Yagisan> the 486 is long dead, but that card worked in my 486, 6x86, k6/2, 2 durons, and and athlon64 system
[10:04] <Yagisan> RAOF, it was for DOOM :D
[10:04] <TheMuso> A little over 10 years ago when we got it.
[10:05] <RAOF> Mmm, the memories.  Hazy as they are :)
[10:05] <TheMuso> And it still works.
[10:06] <Yagisan> that they do
[10:06] <Yagisan> one I can't geta 5V pci slot though - then, its not going to grace any new boxes
[10:07] <Yagisan> I like my new distcc farm - I can build my game in under 22 seconds now
[10:09] <TheMuso> heh
[10:12] <RAOF> Man, plain shell sucks.
[10:14] <RAOF> Amaranth: In here is probably better, because I want to ask whether or not I should care that compizconfig-python is only built against 2.5
[10:14] <\sh> well, it doesn't suck like ruby ;)
[10:14] <Amaranth> RAOF: I dunno, mvo did it
[10:15] <RAOF> The package is crufty.
[10:15] <Amaranth> mvo did it :)
[10:15] <Amaranth> Although I could fix it
[10:15] <Amaranth> I guess
[10:15] <RAOF> I'm doing it
[10:16] <RAOF> There's absolutely no reason to ship static libs for a python module, right :)
[10:18] <Amaranth> right
[10:18] <Amaranth> we need a generic "strip static bullshit" helper
[10:19] <RAOF> Totally.
[11:40] <geser> AndyP: are planing to merge xpdf?
[11:48] <geser> lucas: Hi, http://people.debian.org/~lucas/ubuntu-versions seems to use old Ubuntu data as unimultiverse-outdated-ubuntu.html list packages that are synced for over a week
[11:50] <AndyP> geser: no, wasn't planning on it
[11:51] <AndyP> i also wasn't planning not to :)
[11:52] <geser> are you going to merge xpdf or should I? the last Debian upload closes a CVE
[12:09] <AndyP> geser: i'm pretty busy with other things at the moment so you can go ahead (sorry for the delay)
[12:10] <geser> ok
[12:40] <coNP> ScottK: lighttpd .debdiff for feisty ready
[01:02] <siretart> Riddell: thanks for notice, canonical-sysadmin is contacted
[01:04] <coNP> Does someone have an edgy pbuilder with some computing power and wants me to test a package? :)
[01:05] <coNP> s/test/help testing/
[01:06] <RAOF> For *edgy*?
[01:06] <coNP> edgy-security
[01:06] <coNP> I guess you need an edgy pbuilder for that.
[01:07] <coNP> If I am wrong, feel free to correct me :)
[01:07] <geser> coNP: what do you need tested?
[01:07] <Kmos> I need a debdiff to be checked and uploaded for stunnel4
[01:08] <Kmos> https://bugs.launchpad.net/ubuntu/+source/crywrap/+bug/128634
[01:08] <ubotu> Launchpad bug 128634 in crywrap "[Remove]  Please remove crywrap from Gutsy" [Undecided,Invalid]  
[01:08] <Kmos> http://launchpadlibrarian.net/8668258/stunnel4_4.20-2ubuntu1.debdiff
[01:08] <coNP> geser: bug 127718
[01:08] <ubotu> Launchpad bug 127718 in lighttpd "lighttpd security fixes" [High,In progress]  https://launchpad.net/bugs/127718
[01:09] <coNP> I guess I can install somehow an edgy pbuilder
[01:10] <geser> coNP: yes, create a pbuilder and point it to edgy
[01:11] <geser> coNP: do you need more than a test-build in edgy?
[01:11] <Kmos> geser: can you help me on that crywrap/stunnel4 one ?
[01:11] <geser> Kmos: I'm busy now
[01:11] <coNP> geser: actually I don't need anything from edgy, but maybe should check :)
[01:12] <Kmos> geser: ok, thx anyway
[01:12] <coNP> Maybe does sbuild support better building for different targets?
[01:12] <geser> Kmos: I give it a quick look, what about conflicts? isn't it also needed?
[01:12] <Kmos> hobbsee doesn't asked for that
[01:13] <Kmos> just the two ones i've added
[01:13] <Kmos> but I can change it
[01:14] <geser> Kmos: I'm not sure about the conflicts, I've to reread the Debian policy about it
[01:14] <Kmos> geser: :)
[01:14] <Kmos> http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.5.2
[01:15] <Kmos> geser: i think it don't need it, because the crywrap package will be removed, so it won't do any conflict
[01:25] <lucas> geser: fixing this, thank you
[01:39] <Kmos> http://kmos.homeip.net/~kmos/ddclient/ -> prepared to be uploaded
[01:44] <\sh> guys, someone blogged about an tool for monitoring, was written in java and had an eclipse alike ide...can someone remember the name of this tool?
[01:45] <white> !info teamspeak-server gutsy
[01:45] <highvoltage> doesn't rung a bell :/
[01:45] <ubotu> teamspeak-server: VoIP chat for online gaming (server). In component multiverse, is optional. Version 2.0.23.19-1 (gutsy), package size 1067 kB, installed size 2928 kB (Only available for i386 amd64)
[01:45] <highvoltage> *ring
[01:45] <white> !info teamspeak-server sid
[01:45] <ubotu> teamspeak-server: VoIP chat for online gaming (server). In component non-free, is optional. Version 2.0.23.19-1 (sid), package size 1068 kB, installed size 2820 kB (Only available for i386 amd64)
[02:03] <viviersf> ajmitch, ping :)
[02:13] <coNP> If preparing security patches, should they be against <distro> or <distro-updates>?
[02:14] <white> coNP: which package?
[02:14] <coNP> lighttpd: https://launchpad.net/ubuntu/+source/lighttpd/  
[02:14] <white> coNP: do you have a CVE number?
[02:15] <coNP> No CVE I guess. I speak about bug 127718
[02:15] <ubotu> Launchpad bug 127718 in lighttpd "lighttpd security fixes" [High,In progress]  https://launchpad.net/bugs/127718
[02:15] <white> coNP: well lighttpd has a few security issues
[02:16] <coNP> I based feisty on prev. feisty-security 
[02:16] <coNP> no, sorry
[02:16] <coNP> feisty on prev. feisty, edgy on prev edgy-security
[02:16] <coNP> but dapper has dapper-security and dapper-updates as well
[02:16] <coNP> I guess I should use dapper-security
[02:17] <geser> coNP: should it published through <distro>-security or <distro>-updates?
[02:17] <coNP> geser: Yes. That is the question.
[02:17] <Amaranth> -security
[02:18] <Amaranth> and it should be only security fixes
[02:18] <Amaranth> anything else can come later in -updates
[02:18] <coNP> Thanks, Amaranth. So get latest -security and do an update. 
[02:18] <pschulz01> Greetings.. are there any tools for updating debian/changelog with a python script?
[02:18] <Amaranth> pschulz01: eh?
[02:18] <coNP> dch is a perl script ... :)
[02:19] <pschulz01> Ok.. the package is for a python program though.
[02:19] <geser> coNP: and include the CVE numbers
[02:19] <coNP> geser: in the changelog?
[02:19] <Amaranth> pschulz01: don't automatically update changelog
[02:19] <pschulz01> Amaranth: nightly packaging.
[02:20] <geser> coNP: yes, under references
[02:20] <Fujitsu> pschulz01: python-debian might have what you want.
[02:20] <coNP> Okay, geser, thanks. I guess I have to re-upload my debdiffs then
[02:20] <coNP> No that it would be very hard to include a line in the changelog :)
[02:20] <geser> coNP: when I follow http://secunia.com/advisories/26130/ from your changelog entry I see there several CVEs listed
[02:21] <pschulz01> Fujitsu: Ta :-)
[02:21] <coNP> geser: yes. So I  should also include the CVE numbers as well
[02:21] <coNP> Not only the link to them.
[02:22] <geser> yes
[02:22] <coNP> Cool, thanks. :)
[02:22] <geser> and you can tell LP which CVEs belong to your bug
[02:23] <coNP> I am figuring out right now.
[02:23] <geser> "Link to CVE" in the left pane
[02:24] <coNP> Yes. They are only candidates though.
[02:24] <coNP> Should they be listed anyway?
[02:24] <coNP> I mean CVE candidates
[02:24] <geser> yes
[02:24] <coNP> Okay
[02:29] <RainCT> is a package of a python program supposed to include .pyc files?
[02:30] <Fujitsu> RainCT: Urgh, no.
[02:30] <Fujitsu> RainCT: Please see the Debian Python Policyl
[02:30] <Fujitsu> -l
[02:46] <coNP> ScottK2: do you have time a / o are you in a mentoring mood?
[02:46] <ScottK2> Actually, I'm just about to head out the door.  Sorry.
[02:47] <coNP> Okay. I am going as well. So later then.,
[03:11] <norsetto> HiYa all
[03:13] <Hobbsee> hey norsetto 
[03:14] <norsetto> Hobbsee: Hey Hobbsee
[03:17] <RainC1> someone knows what can be the reason why lintian say "postinst-does-not-call-updatemenus" if there is update-menus on qttube.postinst.debhelper?
[04:24] <Nafallo> hmm
[04:24] <Nafallo> why do we have both roundcube and roundcube-webmail?
[04:32] <geser> because it was first packaged for Ubuntu and entered a year later Debian with a slightly different name
[04:34] <geser> we should add Conflicts/Provides/Replaces: roundcube-webmail to roundcube (or a whole transitional package) and remove roundcube-webmail
[04:38] <xxxxx1> heya ubunteros
[04:52] <norsetto> and ubunteras.....
[04:53] <xxxxx1> norsetto, :)
[04:55] <bddebian> Heya gang
[04:55] <geser> Hi bddebian
[04:55] <bddebian> Hi geser
[04:57] <xxxxx1> hello bddebian 
[04:57] <bddebian> Heya xxxxx1
[04:59] <geser> norsetto: https://wiki.ubuntu.com/BddebianIsAGod :)
[05:00] <norsetto> LOL!
[05:00] <bddebian> pfft
[06:07] <RainC1> gutsy has a help submenu on system, or?
[06:31] <lamont`> E: Build-Depends dependency for ieee80211 cannot be satisfied because the package linux-headers-2.6.17-2-all cannot be found
[06:31] <lamont`> hehe
[06:36] <lamont`> E: Failed to satisfy Build-Depends dependency for onscripter: libstdc++6-4.0-dev
[06:36] <lamont`> thou shalt not build-depend on build-essential packages, esp since sometimes they change names.
[06:37] <lamont`> bugs, even
[06:37] <Hobbsee> lamont`: you've larted the people responsible?
[06:37] <lamont`> Hobbsee: just bitched here is all.
[06:37] <Hobbsee> awww
[06:39] <lamont`> OTOH, this effort is brought to you thanks to k3d taking a long time to build, so that the universe packages are still in sources.list and my script therefore works... once that build is done, then the buildd will just have main there, and, well, ...
[06:40] <lamont`> libpar2 is also guilty of build-depending on a build-essential (and renamed) pacakge
[06:40] <lamont`> I think it build-deps: libstdc++6-dev
[06:41] <AndyP> is it bad practice to put informational messages such as "Creating database, this could take a while" in a postinst script?
[06:41] <lamont`> depends on how long "a while" is, and how impatient the user is likely to become....
[06:42] <lamont`> AndyP: OTOH, if it's going to take that long, launch it in the background, maybe?
[06:43] <AndyP> lamont`: my spidey senses don't like that idea for some reason
[06:45] <xxxxx1> AndyP, it's optional
[06:46] <lamont`> E: Build-Depends dependency for gaim-xmms-remote cannot be satisfied because no available versions of package gaim-dev can satisfy version requirements
[06:46] <lamont`> E: Failed to satisfy Build-Depends dependency for festival-gaim: gaim-dev
[06:46] <lamont`> E: Failed to satisfy Build-Depends dependency for gaim-galago: gaim-dev
[06:47] <AndyP> xxxxx1: which is optional?
[06:47] <xxxxx1> AndyP, verbosity
[06:47] <lamont`> AndyP: the messages about taking a long time
[06:47] <lamont`> and other verbosity. :-)
[06:47] <AndyP> ok, cool
[06:48] <lamont`> and whichever way you choose, expect that someone will file a wishlist-bug against the package wanting the other.
[06:49] <AndyP> no wonder i couldn't find any policy about it :)
[06:50] <bddebian> AndyP: Heya.  Did you fix svk? :-)
[06:55] <AndyP> bddebian: ah sorry, no, couldn't find that patch
[06:56] <bddebian> Bah :-)
[06:56] <AndyP> bddebian: it was a build failure wasn't it?
[06:57] <bddebian> Aye
[06:57] <bddebian> But it built fine for me but not you apparently :-)
[06:58] <AndyP> yeah, i was thinking... do PPAs offer test building on all arches? :)
[06:59] <bddebian> I don't even know what PPA is :-(
[06:59] <geser> bddebian: PPP = Personal Package Archive
[07:00] <geser> AndyP: afaik supports PPA currently only i386 and amd64
[07:00] <AndyP> geser: ah ok
[07:01] <AndyP> bddebian: well if you're confident that it built ok for you i think it's safe to assume that i screwed up and go ahead and upload the new version ;)
[07:02] <AndyP> i have to go for dinner, catch up later
[07:02] <bddebian> Laterz
[07:03] <lamont`> ecasound2.2 also build-deps libwrap-dev, which is not provided by libwrap0-dev
[07:03] <geser> norsetto (and bddebian): https://help.launchpad.net/PPAQuickStart
[07:04] <bddebian> norsetto: geser is DA MAN :)
[07:06] <lamont`> gpe-todo has a versioned build-dep on a virtual package.  for the loss
[07:08] <zul> hey lamont` 
[07:08] <lamont`> morning zul
[07:09] <lamont`> make[1] : Entering directory `/build/buildd/acl2-3.2/books'
[07:09] <lamont`> Sun Jul 22 20:50:52 UTC 2007
[07:09] <lamont`> /bin/sh: time: not found
[07:09] <lamont`> make[1] : *** [all]  Error 127
[07:10] <lamont`> acl2 gets to decide if it want so fail because of bashism, or because it has no build-depends: time
[07:11] <lamont`> how frozen is universe atm?
[07:11] <geser> it's on manual
[07:41] <coNP> ScottK: around? :)
[07:42] <ScottK> Yes
[07:42] <coNP> So I did two debdiffs
[07:42] <ScottK> Did you see keescook's comment on your lighttpd diffs?
[07:42] <coNP> Not yet. Then first I have a look.
[07:42] <coNP> But I guess I'll still have some questions.
[07:43] <ScottK> OK.
[07:43] <coNP> So. I have checked.
[07:43] <ScottK> I'll be mostly here for ~ 4 hours
[07:44] <coNP> http://secunia.com/advisories/26130/ lists other issues. Should these also be fixed? 
[07:47] <ScottK> coNP: I'd say fix all the CVEs you can find patches for.
[07:47] <coNP> Okay. They seems to include links to trac changesets that can be used as patches
[07:48] <coNP> OTOH keescook says list CVEs per patch. That is the natural approach. I choose the "references" section, because https://wiki.ubuntu.com/SecurityUpdateProcedures seems to direct me to do so. I am happy to list them for each patch and maybe we can fix the documentation as well. 
[07:48] <ScottK> Sounds good, I'd talk to keescook about what you are doing and why.
[07:50] <keescook> coNP: feel free to use either references or on a per-patch basis.  the diff I looked at didn't have the CVE in either place.  (maybe I missed it)
[07:51] <keescook> and I wasn't sure what the html~ thing was.  :)
[07:51] <coNP> Oh, sorry. I was only told by geser to add CVEs that I added (home version). But I did not want to upload new debdiffs because I wanted to ask if the other issues should be fixed as well. So first patch-patch-patch, then change logs.
[07:51] <coNP> I am afraid html~ comes from upstream.
[07:51] <coNP> I'll check that as well of course.
[07:51] <coNP> Or was it in the debdiff?
[07:52] <ScottK> It was in the debdiff if I understood correctly.
[07:52] <coNP> Okay, np, I will upload new ones soon anyway.
[07:52] <coNP> (unfortunately no hotplugging :()
[07:56] <bddebian> heh
[09:02] <stgraber> RainCT: just found a small problem with script, it currently creates .tgz based on <distro>-base.tgz which will be a problem if someone create gutsy/i386 and gutsy/amd64
[11:48] <ScottK> coNP: I'll be AFK for several hours now.  Keep up the good work.
[11:58] <RainCT> coNP, stgraber: please test :) http://bazaar.launchpad.net/~rainct/ubuntu-dev-tools/dev
[12:03] <RainCT> good night
[12:13] <bddebian> w00t, go AndyP :-)