[00:26] <lukehasnoname> are there any mirrors for the alpha 5 x64 alternate ISO? cdimage is still giving me trouble
[00:30] <cjwatson> lukehasnoname: https://launchpad.net/ubuntu/+cdmirrors is mostly releases.u.c mirrors, but I'm sure there are some in there with cdimage mirrors too
[00:32] <lukehasnoname> damn, they must all be synced to the same server which does NOT have any alphas, apparently
[00:34]  * TheMuso remembers his ISP mirroring alphas, but can't remember if they still do, and thinks that an Australian mirror may not be the closest geographically.
[02:17] <jerem> ubuntu-fr
[02:18] <jerem> oops
[02:39] <MattJ> Is cdimage.ubuntu.com down intentionally?
[02:41] <james_w> MattJ: http://91.189.88.34/ should get you there
[02:41] <MattJ> james_w: thank you so much :)
[02:41] <james_w> only some of the servers behind cdimage are down, so going directly to one that isn't works
[03:01] <TheMuso> RAOF: If you thought your issue with attempting to switch a stream from hda to your USB speakers was bad, try mine. Pulseaudio completely dies when I either start pulseaudio with my USB sound card connected, or connect my USB sound card while pulseaudio is running.
[03:02] <RAOF> TheMuso: Ba baw!
[03:02] <TheMuso> RAOF: Damn right.
[03:05] <RAOF> I guess that answers the "will 0.9.12 be in Intrepid" question.
[03:13] <TheMuso> Yay! Go assertions! This is a log I'll need to send upstream.
[03:13] <TheMuso> But I think I need to try alsa 1.0.18rc3 first.
[03:15] <RAOF> I'd send you my alsa-source package, but the lappy don't have internets.  And it'll be trivial for you to build one yourself :)
[03:20] <TheMuso> RAOF: Yeah.
[03:21] <TheMuso> gah! Alsa-project.org is down.
[03:22] <RAOF> I _could_ throw it up on my webspace; it's not too hard to hunt down internet for my lappy.
[03:23] <TheMuso> But the ftp is still up.
[03:23] <TheMuso> RAOF: nvm, the ftp part of alsa-project still appears to fucntion.
[03:24] <RAOF> Yay!
[05:52] <TheMuso> RAOF: BTW if you are using alsa-driver 1.0.18rc3, and attempt to change the volume of your hda device, you will get an oops. If you want to be really sure about having this resolved, I've just pulled this patch from one of the alsa dev's git trees, and can make an updated package available if you want it.
[05:53] <TheMuso> RAOF: patch to fix it that is.
[06:01] <RAOF> TheMuso: Hm..  Let me try that.
[06:02] <RAOF> It doesn't seem to oops here?
[06:02] <TheMuso> hrm
[06:02] <TheMuso> it may not be for all hda cards.
[06:02] <TheMuso> but it did for mine, which sent me hunting for the patch I remember seeing on the alsa dev list. :p
[06:04] <RAOF> :)
[06:04] <RAOF> Yeah, I don't think mine does; I'm fairly sure I'm using 1.0.18rc3, and it doesn't oops for me.
[06:05] <RAOF> Yay crazy hda!
[06:05] <TheMuso> Totally agree.
[06:10] <TheMuso> RAOF: Ah thats right, the oops only occurs when changing S/PDIF settings.
[06:11] <RAOF> Heh.  I'm not so much with the digital out.
[06:11] <TheMuso> RAOF: yeah well I was just playing with elements in the mixer when it happened for me. The patch fixes it for me though. and luckily this patch is only for 1.0.18rc3, as in it doesn't affect ubuntu as it stands./
[06:12] <RAOF> :)
[06:13] <TheMuso> ok even the latest alsa lib and driver doesn't stop pulse from dying.
[06:13] <TheMuso> Upstream goes my log.
[06:14] <RAOF> You've upstreamed my underrun logs, right?
[06:35] <TheMuso> RAOF: Will be doing so as well.
[08:14] <soren> I always seem to forget this: Is it necessary to specify a dependency on packages with priority: required?
[08:16] <laptopnenolod> no
[08:16] <laptopnenolod> lets go with iceweasel
[08:16] <laptopnenolod> :D
[08:19] <soren> laptopnenolod: [citation needed]
[08:19] <cody-somerville> bryce, When you're around, could you give me a hand with an x.org issue in Intrepid? :]
[08:20] <laptopnenolod> soren, priority: required packages are provided by the base system, and are not necessary
[08:20] <soren> laptopnenolod: [citation needed] :)
[08:20] <laptopnenolod> soren, the debian policy manual
[08:20]  * cody-somerville notes that laptopnenolod is incorrect.
[08:21]  * soren sighs
[08:21]  * laptopnenolod notes that he is correct, and maintains several critical debian packages (have you enjoyed lilo recently?)
[08:21] <cody-somerville> http://www.debian.org/doc/debian-policy/ch-binary.html#s3.5
[08:22] <laptopnenolod> cody-somerville, priority: required is effectively equivilant to essential: yes
[08:23] <laptopnenolod> infact, i do not know of any packages in priority: required that are not essential: yes
[08:23] <soren> laptopnenolod: Look... I know that debian policy is the source for this source of information, so just referring to that is not very helpful.
[08:23] <soren> laptopnenolod: er...
[08:23] <soren> s/this source/this kind/
[08:23] <soren> I'm looking for a specific reference to support your claim.
 http://www.debian.org/doc/debian-policy/ch-binary.html#s3.5
[08:24] <soren> laptopnenolod: ...which doesn't mention "priority: required" at all.
[08:24] <laptopnenolod> assuming that your packages are essential: yes (which they should be if they are in priority: required)
[08:24] <soren> Er... No.
[08:24] <laptopnenolod> er, yes
[08:25]  * soren rolls eyes
[08:25] <cody-somerville> laptopnenolod, In which cases would priority be set to required and essential not be set to yes?
[08:25] <soren> forget it.
[08:25] <laptopnenolod> Package: bash
[08:25] <laptopnenolod> Essential: yes
[08:25] <laptopnenolod> Priority: required
[08:25] <soren> laptopnenolod: procps
[08:25] <laptopnenolod> cody-somerville, exactly! as i said, they are equivilant
[08:25] <laptopnenolod> soren, that is odd.
[08:25] <soren> No.
[08:25] <soren> It's common.
[08:26] <cody-somerville> laptopnenolod, It isn't a rhetorical question. I'm honestly interested since you seem to be knowledgeable about the essential field.
[08:26] <laptopnenolod> cody-somerville, apparently procps, and some others. enough to make them "common"
[08:27] <laptopnenolod> cody-somerville, but AFAIK debootstrap and cdebootstrap install all packages Essential: yes, and Priority: required .. so they are functionally equivilant.
[08:27] <cody-somerville> I think the reason we don't depend on Essential is to prevent an unresolvable dependency loop.
[08:27] <RAOF> Except you can probably remove a priority: required package without dpkg having a screaming hissy fit?
[08:27] <laptopnenolod> RAOF, yes.
[08:28] <laptopnenolod> so if for whatever reason, Essential: yes is not set, then you should depend on it.
[08:28] <laptopnenolod> but if it's priority: required, then it is most likely also Essential: yes
[08:28] <cody-somerville> Well, regardless, I think we've established a distinction.
[08:29]  * StevenK can't think of a package this is Priority: required that isn't part of the essential set
[08:29] <laptopnenolod> scanning main, i only see less than 10 packages that are not Essential: yes, but Priority: required
[08:29] <soren> There are 67 packages that are required, but only 25 that are essential...
[08:30] <soren> So no, they're not "most likely also essential: yes".
[08:30] <cody-somerville> Regardless, there is a distinction and so although laptopnenolod your answer pragmatically might be correct, it isn't technically correct - and I think soren was looking for the more technical answer.
[08:30] <laptopnenolod> i'm not scanning ubuntu. i should clarify that.
[08:31] <soren> cody-somerville: Quite so. Thank you.
[08:31] <cody-somerville> Btw, is there a pdf version of the Debian Policy Manual anywhere?
[08:31] <laptopnenolod> not that i know of
[08:37] <mdke> cody-somerville: the ubuntu-policy package appears to have a pdf in it
[08:37] <cody-somerville> \o/
[09:02] <cjwatson> laptopnenolod: you're definitely incorrect, sorry. adduser and procps are the usual exceptions
[09:02] <laptopnenolod> i believe we settled this already.
[09:02] <cjwatson> it wasn't clear, and I wanted to give soren a clear answer
[09:03] <cjwatson> FWIW the main purpose of required these days is to be the first stage of debootstrap, i.e. stuff that's unpacked with ar and tar the first time round
[09:04] <cjwatson> for example I wanted there to be an answer from somebody else who maintains key Debian packages - I trust you use your password file ;-)
[09:06] <laptopnenolod> cjwatson, i mentioned [c]debootstrap already :P
[09:06] <cjwatson> (oh and of course libraries must never be Essential: yes even if they're required - Essential is *not* closed under dependency - but they're sort of an edge case since you typically versioned-dep on them)
[09:06] <soren> cjwatson: Thanks very much.
[09:06] <laptopnenolod> in other news, can you guys replace abrowser with iceweasel. thanks
[09:06] <cjwatson> I think that would be very confusing since our firefox package is not based on Debian's iceweasel package
[09:07] <cjwatson> it would imply some kind of commonality that simply isn't there
[09:07] <laptopnenolod> yes :P you should work with Debian wrt packaging and tell mozcorp to go away
[09:07] <cjwatson> (right now, at least)
[09:10] <laptopnenolod> i haven't even seen the EULA nagbox yet. my intrepid box is at home :(
[09:11] <cjwatson> the unfortunate part about telling mozcorp to go away is that history demonstrates that that means our upstream bugs will suddenly get a lot less attention :-/
[09:11] <cjwatson> which is one reason it isn't a slam-dunk
[09:15] <laptopnenolod> i need to upgrade my laptop to either debian lenny proper or intrepid; right now it is running a derivitive which is more of a personal sandbox... but the concepts i am playing with are definitely a lenny+1 if not lenny+2 thing. decisions, decisions :P
[09:17] <laptopnenolod> also working on a shadowed source package format that says "take package from X and apply these changes to it"... definitely lenny+2 imo there
[09:39] <Adri2000> so, no one wants to comment on my email about vsftpd? or is it still too early monday morning? :p
[09:39] <Adri2000> err, that was for -server sorry
[09:42] <cjwatson> (actually not all buildds are down; we should still have one per architecture, but the rest are being moved around)
[09:50] <dalew> I have the following command "apt-get -b source linux-image-2.6.27-3-generic" which fetches and build the kernel, the issue I'm having is that I need it to build a diffferent version of the source which is modified, any ideas on how to achieve this?
[09:50] <cjwatson> apt-get source (no -b), cd directory-it-gives-you, hack hack hack, debuild -b
[09:52] <dalew> apt-get source linux-2.6.26
[09:52] <StevenK> Intrepid uses 2.6.27
[09:52] <dalew> results in "E: Unable to find a source package for linux-2.6.26"
[09:52] <cjwatson> the source package is just 'linux'
[09:53] <dalew> I need to use the source I have.
[09:53] <cjwatson> why not just build it in the usual upstream way, then?
[09:53] <dalew> because if I have to answer one question then I'm foo-bared.
[09:54] <cjwatson> you could copy in the debian directory from the current source, but configs will be out of sync and you will likely have to answer questions
[09:54] <dalew> I can't be prompted for any information, it has to build without any user interaction.
[09:54] <cjwatson> I think we need to understand exactly what you're actually trying to achieve here
[09:54] <dalew> I want to build a modified source and creaet the .deb pacakges.
[09:55] <cjwatson> but apparently noninteractively; why?
[09:55] <dalew> because I want the build to work on all hardware and I don't have time to learn the ububtu way.
[09:55] <cjwatson> dalew: you could use make-kpkg from the package 'kernel-package', if you just need to build debs
[09:55] <cjwatson> you will still need to provide usable configs, though
[09:56] <dalew> with the command used to build intrpid I was asked no questions, exactly how i need it to be.
[09:56] <cjwatson> dalew: do you only need to build one specific piece of modified source, or arbitrary modified source?
[09:56] <dalew> the who thing.
[09:56] <dalew> whole
[09:56] <cjwatson> what does that mean?
[09:56] <dalew> build it all.
[09:56] <cjwatson> I mean, do you want to be able to build anything from 2.6.ancient through to 2.6.future, or what?
[09:57] <cjwatson> or do you only care about just one version?
[09:57] <cjwatson> because you really do have to provide useful configs, which need a certain amount of human attention
[09:57] <dalew> I have a modified linux-2.6.26 source based on the rc5
[09:57] <cjwatson> it would be much easier if you only had to care about one version
[09:58] <dalew> really,  the following command asked for nothing form me "apt-get -b source linux-image-2.6.27-3-generic"
[09:58] <cjwatson> yes, you said.
[09:58] <dalew> that fetched the source, I already have the source I want to use.
[09:58] <cjwatson> that doesn't mean we have magic integration to build arbitrary source.
[09:59] <cjwatson> dalew: how about you grab the source package from here: https://launchpad.net/ubuntu/+source/linux/2.6.26-5.17 - that's the last 2.6.26 we released
[09:59] <cjwatson> dalew: unpack it with 'dpkg-source -x linux_2.6.26-5.17.dsc', and copy the debian directory into your modified source
[09:59] <dalew> because it will not contain my changes.
[09:59] <cjwatson> dalew: then debuild -b
[09:59] <cjwatson> dalew: because you're not listening to me!
[10:00] <dalew> ah but I see what your getting at.
[10:00] <cjwatson> dalew: copy the *debian directory*. not the whole thing.
[10:00] <dalew> sec.
[10:00] <cjwatson> that will include configs
[10:02] <dalew> darn, many sources to pick, the first generic is acceptable?
[10:02] <cjwatson> no no, those are binaries
[10:03] <cjwatson> the three links at the top of that page - .orig.tar.gz, .diff.gz, and .dsc
[10:03] <dalew> downloading all 3
[10:03] <cjwatson> (you can actually do this with just the .diff.gz, which is less of a download, but the process is more involved because you then have to filter out changes to the kernel source itself)
[10:06] <dalew> ok got all 3 files.
[10:08] <dalew> extracting.
[10:09] <tkamppeter> pitti, hi
[10:10] <dalew> ditto'd the debian dir.
[10:14] <dalew> next step in this process?
[10:14] <cjwatson> 09:59 <cjwatson> dalew: then debuild -b
[10:15] <dalew> gotcha.
[10:15] <cjwatson> in the directory just above debian/
[10:16] <dalew> http://acm.pastebin.com/d48ce1516
[10:16] <dalew> which is the root source directory.
[10:16] <cjwatson> you're going to have to sync up debian/config/ with your source
[10:16] <dalew> how do I do that?
[10:17] <cjwatson> the reason our source package builds noninteractively is that that's already been done by the maintainer
[10:18] <cjwatson> you could try 'debian/rules updateconfigs' to see if it can be done automatically. Make sure that you have a backup of the source though
[10:21] <dalew> when I run it it keeps deleting the debian directory.
[10:22] <cjwatson> *blink*
[10:23] <cjwatson> I don't see anything that would do that and it's hard to believe. debian/ is important to source packages and our code doesn't typically run around deleting it ;-)
[10:28] <dalew> after the update debuild -b ran debian/rules clean and it was gone.
[10:29] <dalew> started fresh extract, copy and updateconfig seems to be building now.
[10:29] <cjwatson> there's no way that 'debian/rules clean' should remove debian/
[10:30] <cjwatson> but try just 'debian/rules build && fakeroot debian/rules binary', then
[10:30] <dalew> well I don't know which command did it but I do know it vanished.
[10:30] <dalew> debuild -b seems to be working ATM
[10:32] <dalew> http://acm.pastebin.com/db013864
[10:34] <dalew> here's the whole session, shwoing thta it starts out there but then fails with it missing.  http://acm.pastebin.com/d3c8d1485
[10:35] <NCommander> cjwatson: what package setups up autologin on the liveCD?
[10:35] <cjwatson> NCommander: casper
[10:35] <NCommander> cjwatson: ok, since autologin broke on the xubuntu livecd
[10:35] <NCommander> (not a good thing for the CD to prompt for a username and password)
[10:36] <dalew> query, what are .udeb files?
[10:37] <cjwatson> dalew: that session looks like you had previously used make-kpkg or 'make deb' or something on that source tree, and it thought it was cleaning up after that
[10:37] <cjwatson> dalew: udebs are micro-debs used by the installer
[10:38] <cjwatson> NCommander: what display manager do you use? has this ever worked for Xubuntu?
[10:38] <NCommander> cjwatson: Xubuntu uses GDM. It worked in Hardy since I used an Xubuntu liveCD to install
[10:38] <dalew> ok, it's from another attempt to follow instructions that didn't give a working install, your instructions seem to be going significantly further
[10:39] <cjwatson> NCommander: check /var/log/casper.log to see if there's anything interesting in there
[10:39] <NCommander> Yeah, I will
[10:40] <dalew> cjwatsom: thanks
[10:40] <NCommander> THere is a Critical bug against this on xubuntu-meta, and a New/Unclassified one on casper
[10:41] <cjwatson> dalew: no problem
[10:41] <NCommander> cjwatson: any good ideas what might be causing this to go boom
[10:42] <cjwatson> NCommander: nothing comes to mind; if it's just gdm then it should be the same as Ubuntu, unless your configuration file location is different or something
[10:43] <NCommander> cjwatson: well, I *think* I found the problem
[10:43] <NCommander> cjwatson: it looks like someone removed casper from the live seed
[10:44] <NCommander> cjwatson: it should be in that seed, right?
[10:44] <cjwatson> yes
[10:45] <cjwatson> oh, no, it doesn't need to be
[10:45] <cjwatson> NCommander: livecd-rootfs already deals with adding it
[10:46] <NCommander> cjwatson: that seems to be missing too
[10:46] <cjwatson> yes, of course. livecd-rootfs isn't installed on the live CD, it's what builds the live filesystem
[10:47] <cjwatson> http://cdimage.ubuntu.com/xubuntu/daily-live/current/intrepid-desktop-i386.manifest says casper is on your live filesystem
[10:49] <NCommander> oh
[10:49] <NCommander> Thanks
[10:49] <NCommander> jelmer: ping
[10:52] <dalew> cjwatson: just "dpkg -i" the image and header files is all that I need to do or should I do all of the .deb files??
[10:52] <cjwatson> image and header should be fine
[10:53] <dalew> it made a lot of .deb files, normal?
[10:55] <dalew> ok, bootable, thank you for your time.
[10:55] <cjwatson> yep, it's normal that it made lots
[10:56] <dalew> I can imagine how longh it takes to build on fast machine, the dual 3ghz quad core Xeon does it in no time but the screen scrolls so quickly that it's hard to read anything.
[10:56] <dalew> what is the average build time?
[10:57] <dalew> or is under 5 minutes considered normal?
[11:08] <Koon> doko: the libnss-mdns recommend in openjdk-6 was reintroduced in 6b12~pre1-0ubuntu2, I reopened bug 261847
[11:09] <dalew> cjwatson, those would be generic installations meaning any CPU or are they going to be specific to my Xeon's?
[11:09] <cjwatson> dalew: they ought to be generic back to i686 (supposed to be i586 but that was a bug in our 2.6.26 configs)
[11:10] <dalew> oldest I got is Pentium-D so I should be safe then.
[11:10] <dalew> mistake, Celeron-D on a D915G
[11:11] <dalew> still pentium 4 class
[11:11] <dalew> supposrting SSE3
[11:14] <NCommander> lamont: are you around?
[11:19] <tjaalton> hm, are the lpia buildd's really i386's?, or can I use DEB_HOST_ARCH to determine that a package is being built on lpia?
[11:20] <kelemengabor> mvo__: could you fix please bug 270035? it' only one line, but prevents the generation of the pot file
[11:21] <mvo__> kelemengabor: sure
[11:21] <kelemengabor> thanks :)
[11:27] <cjwatson> tjaalton: they're i386 under the covers, but DEB_HOST_ARCH should work anyway
[11:28] <tjaalton> cjwatson: thanks
[11:28] <cjwatson> Mithrandir: could you change https://code.launchpad.net/casper/trunk to point to ~ubuntu-core-dev/casper/trunk, please? (I moved the old branch out of the way due to brokenness.)
[11:34] <TheInfinity> hello ... i read about the plan integrating vmware-player into hardy partner sources ... does anybody know something about the plan when this will be done?
[11:42] <dalew> cjwatson, you seem very knowledgeable about ubuntu and the builds, is it possible to have a binary with multiple arches, say i386 and ppc that would work in their associated environments?
[11:43] <cjwatson> dalew: we don't have any real "fat binary" support that I know of, no
[11:44] <dalew> shame, it would be nice to have a single installation that works on PPC or Intel based machines.
[11:46] <dalew> oh oh, cleaned up everything, thought I'd make a fresh build in a build location and it generated the header and doc packages but then failed, use the same commands verbatim.
[11:50] <NCommander> cjwatson: I thought ELF supported fat binaries
[11:51] <NCommander> dalew: it would be in theory possible to create a universe installation disc for PowerPC and i386/amd64 since OpenFirmware doesn't use El Torro booting
[11:52] <cjwatson> NCommander: in theory I think so, but there's no distro-level support for it
[11:52] <cjwatson> you would almost certainly run into issues with per-architecture files that aren't ELF objects
[11:53] <broonie> IIRC one of the Debian multi-arch install images is i386/amd64/powerpc (but that's essentially just 3 netinst images glued together I believe).
[11:53] <NCommander> cjwatson: multilib would help resolve that if Debian ever got around to supporting it
[11:53] <cjwatson> NCommander: I think that's very optimistic, even given the basic ground level of optimism involved in assuming that multiarch will happen any time soon
[11:54] <NCommander> cjwatson: Solaris has multiarch (or something similar), so its at least possible
[11:54] <cjwatson> Debian's multiarch proposals is not intended to resolve any more than providing multiple trees of libraries; it doesn't even contemplate addressing multiple-architecture binaries
[11:54] <NCommander> Of course, that multiarch has made it rather difficult to make a nexenta solaris-amd64 port
[11:54] <cjwatson> s/ is / are /
[11:55] <cjwatson> and it doesn't even start to address things like providing the completely different sets of hardware support that would be required for i386+powerpc
[11:56]  * NCommander nods
[11:56] <cjwatson> broonie: right, that just exploits CD layout tricks to make them all boot and then has a giant composite apt archive
[11:56] <NCommander> I was just saying that multiarch would be a step in the right direction
[11:56] <NCommander> cjwatson: how much do you know about the acceptance of new ports, I wanted to ask about the possibility of an offical (community supported) Solaris Ubuntu Server port
[11:56] <cjwatson> we haven't done it often enough for there to be a real process
[11:56] <cjwatson> by default, it would be a decision for the technical board
[11:57] <NCommander> cjwatson: I guess the next question is how is the easiest way I can ask (the port already semi-exists in the form of nexenta, although it needs some clean up before it would meet Ubuntu standards w.r.t to source cleaniness)
[11:58] <cjwatson> the main problem with new ports is that there *has* to be a really solid more-than-one-person commitment to keeping it going. hppa has been a problem because it lags behind and developers occasionally end up so annoyed by e-mail about it that they invest time to clean it up
[11:58] <cjwatson> I don't think we should be accepting one-man-band ports
[11:58] <NCommander> It already has a community
[11:58] <NCommander> nexenta is based off ubuntu dapper and hardy
[11:58] <NCommander> six developers, and 50+ users
[11:58] <cjwatson> and they must not involve source changes that would be unacceptable in Ubuntu; that seems obvious but is perhaps worth saying
[11:59] <NCommander> cjwatson: of course
[11:59] <cjwatson> sure, but that only helps if they would actually be interested in developing for Ubuntu itself and qualified to do so
[11:59] <cjwatson> also, 50+ users is not worth the immense investment in terms of archive space
[11:59] <NCommander> cjwatson: 50+ is the debian minimin for an offical port. Just saying.
[11:59] <cjwatson> small user bases like that should be done separately, IMO
[11:59] <cjwatson> NCommander: that doesn't change my opinion
[12:00] <NCommander> I understand.
[12:00] <cjwatson> every new port adds a significant fraction to the time that the hourly archive run takes, for instance
[12:00] <NCommander> Right now, I'd just ask the technical board if such a port would be acceptable (since its non-Linux), and then proceed from there on moving towards matching up with Ubuntu and then slowly working towards becoming an offical port
[12:00] <cjwatson> that time is already unacceptably long
[12:01] <NCommander> cjwatson: its 40 minutes * arch last time I checked
[12:01] <cjwatson> no it's not
[12:01] <cjwatson> never has been
[12:01] <NCommander> apt-ftparchive was in that ballpark for me on a clean run ont the archive with no database files
[12:02] <cjwatson> currently it takes about an hour for all architectures. But when you consider that the cron job is hourly, that's not to be sneezed at
[12:02] <cjwatson> we need it to take significantly less than an hour
[12:02] <cjwatson> clean run is not the normal case
[12:02]  * NCommander nods
[12:02] <NCommander> What takes an hour in the script to run?
[12:03] <cjwatson> so at the moment I would be inclined to say that the performance problems MUST be fixed before we can add new ports.
[12:03] <cjwatson> err, all sorts of things. The Soyuz developers are aware of a number of problems and several of them are high-priority
[12:03]  * NCommander had no intention of instantly creating this port out of nowhere, just if Nexenta should be making moves to match Ubuntu so if/when they can be offically accepted its a fairly streamlined process
[12:03] <cjwatson> apt-ftparchive itself takes about 20 minutes
[12:04] <ogra> anyone familiare with mtools ? "mcopy -i imagefile.img ::file ." would copy file out of imagefile.img into $(pwd) ... is there a way to defne a secont imagefile as target ?
[12:04] <ogra> *second
[12:04] <liw> ogra, I don't know if mtools can do it (it might), but would it not be simpler to loop mount the image?
[12:05] <ogra> liw, that would require root/sudo :)
[12:05] <ogra> i'm looking for a userspace way
[12:05] <ogra> sadly defining a second -i option doesnt do what i expected
[12:05] <wgrant> cjwatson: Do you know how much faster NMAFA is that apt-ftparchive?
[12:06] <cjwatson> ogra: mmount two images on separate drive letters?
[12:06]  * ogra reads about mmount
[12:06] <cjwatson> wgrant: not in terms of hard numbers, no
[12:06] <Mithrandir> cjwatson: done
[12:06] <cjwatson> Mithrandir: thanks
[12:07] <ogra> cjwatson, hmm, seems not to work without having a mtoolsrc
[12:08] <cjwatson> ogra: you could just copy out and then copy in ...
[12:09] <dalew> everyone, thanx for your time, time to head out to work so enjoy.
[12:09] <ogra> cjwatson, yeah, thats an option
[12:09]  * dalew shakes cjwatson's hand.
[12:11] <cjwatson> ogra: you can set MTOOLSRC to a local mtoolsrc file
[12:11] <ogra> yeah, thats what i thought about first
[12:11] <ogra> but i want a single script ...
[12:11] <ogra> sadly there are no global vars i could just set
[12:12] <cjwatson> export MTOOLSRC="$(tempfile)"; trap 'rm -f $MTOOLSRC' EXIT HUP INT QUIT TERM; ...
[12:12] <cjwatson> can still be in a single script :)
[12:12] <ogra> lol
[12:12] <ogra> wow
[12:12] <ogra> indeed
[12:13] <cjwatson> actually possibly "rm -f ..." rather than 'rm -f ...' there. but you get the idea.
[12:13] <ogra> yeah
[12:13]  * ogra hugs cjwatson ... genious
[12:15] <ogra> liw, the idea is that most .img files we use are vfat anyway ... i want to have a script set for any user to create and modify images without needing root
[12:15] <dalew> cjwatson: was just making notes on what I've done tonight, you gave me some alternate build commands which partial was "debian/rules build" but I only copied half the line, was going to try them later and see if it gave a better build., "Konversation" doesn't seem to keep logs.
[12:15] <liw> ogra, ack, for that loop mounting isn't useful, unless you only run the script on systems where you are willing to set up /etc/fstab to have the loop mount with user option
[12:16] <dalew> nevermind, I found the log file.
[12:53] <jelmer> NCommander, pong
[12:54] <NCommander> jelmer: I was going to ask what patch system you perfer for samba4, but I found that quilt was already enabled in the build-deps so I used that to fix the build on Ubuntu
[13:02] <lamont> NCommander: back home now, generally not online at 4AM.
[13:02] <lamont> 6AM, OTOH
[13:02] <NCommander> lamont: I was going by your /away status ;-)
[13:03] <lamont> heh.  away means I either remembered to set it, or I killed the client
[13:03] <lamont> or I'm back and forgot to clear it.
[13:03] <NCommander> lamont: :-P
[13:04] <NCommander> lamont: my question was what's the easiest way to talk to the TB about the possibility of having a community-supported solaris-* port (essentially merging nexenta's efforts into our own), since an Ubuntu Solaris server would sport powerful features like ZFS
[13:05]  * lamont generally finds email to be a good way to talk to the TB
[13:05] <NCommander> point me to your leaders email address ;-)
[13:07] <azeem> "The Ubuntu Technical Board can be reached by email at technical-board@lists.ubuntu.com"
[13:07] <mvo> soren: do you happen to know what it means when I get "virtio-net header not in first element" ?
[14:05] <soren> mvo: Not off the top of my head, no. I have sort of a guess, but it doesn't make much sense, I think. Where are you seeing it?
[14:07] <mvo> soren: bug 270495
[14:10] <davmor2> Is there a reason for the ula in FF3?
[14:10] <soren> mvo: When did this happen? What changed?
[14:12] <cjwatson> davmor2: there's an extensive bug log on the subject
[14:13] <davmor2> cjwatson: ah okay ta just noticed it and thought I'd check if there was a reason
[14:13] <mvo> soren: it happens shortly after I boot (can't give you details, it exists when the message appears)
[14:13] <soren> mvo: I mean when did it stop working?
[14:13] <wgrant> Extensive doesn't quite cover it any more.
[14:13] <soren> mvo: 2.6.27-3, perhaps?
[14:14] <mvo> soren: I think it was not working with 2.6.27-2 too, I'm currently trying to figure out if it depends on the guest or not
[14:15] <mvo> soren: I will post more information into the bugreport, I was just curious if it is something known :)
[14:15] <soren> mvo: I've not stumbled upon it before, no.
[14:15] <mvo> thanks!
[14:22] <NCommander> siretart: you around?
[14:35] <siretart> NCommander: at work.
[14:35] <NCommander> siretart: when you get home, there is a bug I'd like you to review (needs to be run by -release and ScottK wanted me to ask you) cause it required a dependency change
[14:36] <siretart> NCommander: what's the number?
[14:37] <NCommander> siretart: https://bugs.edge.launchpad.net/ubuntu/+source/gnucash/+bug/270200
[14:38] <siretart> NCommander: did you already talk to thomas about this? How about filing this as a bug in debian and add a remote bugwatch on it?
[14:38] <NCommander> siretart: bug is in debian, no response
[14:39] <NCommander> The original bug had the watch
[14:39] <NCommander> Hold on, I'll readd it
[14:39] <siretart> NCommander: but I don't see why it needs a confirmation from -release?
[14:40] <NCommander> siretart: I was told that since it required a change in dependencies, it required approval
[14:40] <NCommander> siretart: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498775 - debian bug
[14:40] <munckfish> cjwatson: hi. Just to let you know I'm sort of back on the PS3 trail again. I have a stable kernel build (awaiting a git pull) so hopefully I can start to follow up some of the other issues on LP soon.
[14:41] <cjwatson> munckfish: cool, that's good to know
[14:41] <NCommander> Launchpad won't let me add a remote bug watch
[14:42] <siretart> NCommander: I don't have any objections to that if you say you tested it and can confirm that it works okay for you
[14:42] <NCommander> siretart: works for me
[14:42] <NCommander> siretart: would you mind commenting that, and I'll subscribe u-u-s
[14:46] <siretart> NCommander: sure, go ahead
[15:19] <calc> companies that serve 2MB pdf's for disaster recovery information to potentially 2mil affected customers are pretty dumb
[15:19] <calc> i guess they never heard of plain text
[15:20] <calc> if all customers downloaded this data which is updated twice a day they would be doing ~ 7.25TB/day transfer
[15:20] <calc> needless to say their site is constantly falling over
[15:27] <calc> lovely now all i'm getting is IIS error messages :\
[15:39] <kwwii> asac: what are the chances of getting this patch applied to firefox for intrepid? https://bugzilla.mozilla.org/attachment.cgi?id=332569
[15:41] <tseliot> seb128: I have adapted my patches so as to make it easier for upstream to adopt them. If they are accepted we will only need a really small patch to make the xrandr capplet work automagically as planned. Here's the link to the bug which you filed: http://bugzilla.gnome.org/show_bug.cgi?id=545118
[15:42] <seb128> tseliot: thanks
[15:43] <asac> kwwii: what bug id is that?
[15:44] <tseliot> seb128: of course, if they are not accepted, I will write other patches with the non-upstream functions marked with an "ubuntu" prefix. I guess it won't take long to have a reply from upstream since feature freeze is near, right?
[15:44] <seb128> tseliot: they are already feature and api frozen, code freeze is today for GNOME
[15:45] <seb128> tseliot: let's wait some days for commnents and then distro patch that for intrepid
[15:45] <tseliot> seb128: ok, thanks
[15:46] <kwwii> asac:  https://bugzilla.mozilla.org/show_bug.cgi?id=405421
[15:47] <NCommander> seb128: so uh, first time I ever uploaded an FTBFS on i386 :-/
[15:47] <seb128> NCommander: soyuz bug
[15:47] <NCommander> \o/!
[15:47] <NCommander> yay for bugs
[15:48] <mathiaz> seb128: hi - I've ran into bug 121341 for the python-gobject package.
[15:49] <seb128> hey mathiaz
[15:49] <mathiaz> seb128: one solution could be to switch to python-central
[15:49] <mathiaz> seb128: what do you think about it ?
[15:49] <seb128> mathiaz: I would prefer avoid having to do this
[15:50] <asac> kwwii: do we have a ubuntu bug for this too? if so, lets milestone that for beta
[15:50] <mathiaz> seb128: the other option is to fix python-support then
[15:50] <cjwatson> the word "non-trivial" comes to mind
[15:51] <seb128> mathiaz: the situation just sucks, pygobject is almost on sync on debian but changing debian to python-central will not be possible
[15:51] <seb128> one of the active pkg-gnome member is the python-support guy and he's against python-central
[15:51] <mathiaz> seb128: hm..
[15:52] <seb128> and I already discussed the issue with him and he says there is no clean way to have things still working during an upgrade and he doesn't want to do that in python-support
[15:52] <mathiaz> seb128: ok - I'll have to come up with another solution then..
[15:53] <kwwii> asac: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/226139 seems like the right one
[15:55] <asac> kwwii: ok thanks. I'll triage it and milestone
[15:57] <kwwii> asac: great, thanks
[16:02] <dholbach> mathiaz: https://wiki.ubuntu.com/GetRidOfPythonCentralAndSupport :)
[16:12] <mathiaz> dholbach: awesome ! :)
[16:12] <mathiaz> dholbach: but that won't make it in intrepid...
[16:12] <dholbach> mathiaz: no, unfortunately not
[16:13] <mathiaz> dholbach: yop - and I'm currently stuck in landscape-client because of this bug... So I'll have to find a workaround this ASAP
[16:16]  * lamont wonders why in the hell libgnome-desktop-dev DEPENDS on dbus
[16:17] <cody-somerville> lamont, its the new fad. headers communicate to one another via dbus.
[16:17] <lamont> libgnome-desktop-dev -> libgnome-desktop-2-7 -> libgconf2-4 -> libdbus-1-3 -> dbus
[16:18] <lamont> which really leads to the question of why libgnome-desktop-dev Depends on libgnome-desktop-2-7, I suppose
[16:18] <lamont> everything past that at least kind of makes sense
[16:18]  * lamont files a bug
[16:19] <jcristau> lamont: having a libfoo.so symlink without the destination would be pretty dumb
[16:19] <seb128> lamont: because the actual lib is there?
[16:19] <lamont> seb128: let me rephrase that... why can't I have the -dev package installed without having DBUS RUNNING?
[16:19] <jcristau> the libdbus -> dbus dependency, otoh
[16:20] <lamont> ah, that does make more sense
[16:20] <seb128> it's a recommends
[16:20] <seb128> not a depends
[16:20] <seb128> don't install recommends?
[16:20] <seb128> I think it's a fair recommends use
[16:20] <lamont>  libgnomevfs2-0 depends on dbus (>= 0.90).
[16:21] <seb128> right, that's because the gnome-vfs-daemon needs dbus to run
[16:21] <james_w> bug 270500
[16:22] <cjwatson> Keybuk keeps saying that upstart is going to depend on dbus eventually anyway
[16:22] <lamont> seb128: so... why can't I have libgnomevfs2-dev installed on a machine that lacks dbus?
[16:23] <lamont> cjwatson: I don't need upstart in this chroot
[16:23] <lamont> well, maybe, I suppose
[16:23] <cjwatson> upstart is in the required seed ...
[16:23] <lamont> OTOH, if dbus actually _started_ it would kind of help things, I suppose
[16:24]  * lamont mounts /proc :-(*
[16:25] <seb128> lamont: because gnome-vfs needs dbus
[16:26] <lamont> meh.  it'd be nice to be able to complile things without dbus pain
[16:26] <lamont> amusingly, dbus fails to remove if you do a /etc/init.d/dbus stop first
[16:26] <lamont> for the total policy-violating fail
[16:42] <lamont> in any case, it'd be nice if libgnome-vfs split the library out, IMO
[16:43] <seb128> lamont: libgnomevfs is deprecated and I doubt it'll get lot of changes
[16:44] <lamont> seb128: ah, well, that makes it self-correcting with time.
[16:44] <seb128> right
[17:17] <cjwatson> dendrobates: working on bug 269040, FYI; unfortunately my first solution is slothfully slow because it starts up debconf once per task, so, err ... I'll try not to do that
[17:18] <mterry> bryce: If I were trying to start xorg on a different VT without it immediately taking over the screen, do you have advice on how to do that?  (for the known-driver case; like, what code changes I might have to make, is it possible, etc.)
[17:21] <bryce> mterry: hmm
[17:21] <jcristau> mterry: x can't start without ownership of the vt afaik
[17:23] <mterry> jcristau: :-/  X can do stuff on a non-foreground VT, so I thought it would be possible.
[17:23] <bryce> mterry: there is a -keeptty switch but sounds like that makes it reuse the current vt
[17:23] <bryce> mterry: if you're up for some X hacking, I imagine it might be possible to modify it to add a switch to permit that
[17:24] <mterry> bryce: Yeah, the vt related command line arguments aren't useful.  My driver has a -noswitchvt that doesn't do what it sounds like.  Stops switching on shutdown or some such
[17:24] <bryce> mterry: what exactly are you aiming to do?  maybe there's another way to do it?
[17:24] <mterry> bryce: Fair question.  I'm trying to make the bootup a tad smoother.  Start gdm/X on a different VT, keep usplash up, and when GDM is fully up, switch VT
[17:25] <bryce> ahh
[17:26] <mterry> bryce: re: X hacking, I can comment out the obvious VT switching bits in the initialization code, but the driver still seems to draw to the screen (keyboard no longer works w/o the vt switching, so I assume the console didn't switch, but driver still p0wnd my display)
[17:26] <cjwatson> I didn't think that was possible. Surely the driver needs to fiddle with registers before it can know whether it's going to be able to come up.
[17:26] <bryce> mterry: have you looked into the kernel modesetting stuff?
[17:27] <jcristau> mterry: gdm can't be 'fully up' before you've switched vt..
[17:27] <mterry> bryce: I haven't.  I'm peripherally aware of the work, but it's not ready for the drivers/codebase I'm looking at (hardy)
[17:27] <bryce> mterry: keep in mind that that stuff may hit in Jaunty, which may shake up that portion of the boot process
[17:28] <bryce> ah, if you're basing on hardy, yeah that won't be of use to you
[17:37] <bryce> mterry: well you might want to contact the driver developers directly
[17:37] <bryce> mterry: sorry, did you mention which driver you were targeting?  We can suggest a person to contact.
[17:38] <mterry> bryce: The intel/psb drivers
[17:40] <bryce> mterry: -psb?
[17:40] <mterry> bryce: -intel and -psb, yeah
[17:41] <bryce> ok, for -intel the guy to contact is Jesse Barnes at Intel
[17:42] <bryce> -psb is a bit of a special case
[17:43] <bryce> it's developed by tungsten graphics for intel, but I don't think they provide community support, only contract-based support
[17:43] <bryce> so I'd start with Jesse; he's very knowledgeable and hopefully can indicate if it's doable at all
[17:43] <mterry> bryce: OK.  Thanks for the help!
[17:44] <bryce> if it is, he may also be able to help get you in contact with some -psb folks; if not, let me know and I can give you a name
[17:44] <cjwatson> mterry: the claim is simply that X has hardwired assumptions that screens have been initialised before actually starting to process any X events. We're just warning you that this is a rabbit-hole. :-)
[17:44] <bryce> yep
[17:46] <mterry> cjwatson: When you say 'screens', you're talking about internal data objects, eh?  Those could be created in the background without actually drawing on the screen, I had thought.  But I agree it's a rabbit hole.  :(
[17:47] <cjwatson> I mean the internal objects, yes
[17:59] <Chipzz> !release | chipzz
[18:07] <dendrobates> cjwatson: is it possible for me to blacklist packages in server-ship and not affect the other seeds?  soren believes not.
[18:10] <theclaw> how can I prevent a package from being upgraded?
[18:12] <azeem> theclaw: sounds like a #ubuntu question
[18:12] <azeem> theclaw: or do you mean in the archive, not on your system?
[18:13] <theclaw> azeem: okay
[18:23] <slangasek> has requestsync recently lost its support for an argument specifying whether to subscribe ubuntu-archive directly or to subscribe sponsors?
[18:23]  * ScottK-laptop wonders if perhaps the subscribe sponsors option ought to be the default.
[18:25] <slytherin> Can anyone please tell me if gstreamer base plugins have standing freeze exception?
[18:27] <slangasek> hmm, and somewhere along the line people started appending 'ubuntuX' to the version numbers of ubuntu-dev-tools
[18:29] <cody-somerville> lol
[18:36] <slytherin> does anyone know where can I find slomo?
[18:36] <james_w> slangasek: it tries to work it out for you now
[18:37] <slangasek> james_w: which can't possibly work if you're submitting the bugs by email, which is still a supported option
[18:37] <slangasek> I've filed a bug and subscribed jpds to it, since he seems to have driven these changes
[18:37] <james_w> yeah, I think it does the lookup on http first
[18:38] <james_w> though I haven't managed to get requestsync to actually request anything for quite a while now
[18:38] <slangasek> hmm. eew?
[18:39] <slytherin> james_w: me too. I simply copy it's report and create a bug manually
[18:44] <seb128> slytherin: slomo is on holidays I think, why?
[18:44] <seb128> slytherin: gst* don't have a standing exception but I do bug fix updates usually
[18:45] <slytherin> seb128: There is a bug with DVD playing which is fixed in gst plugins base. I was thinking of I should try backporting the bug if new pre releases are not getting packaged before beta freeze
[18:45] <slytherin> s/of/if
[18:45] <seb128> slytherin: feel free to do the backporting
[18:46] <seb128> dunno what schedule they have for the next tarballs
[18:46] <slytherin> seb128: The pre release tarballs are available. And slomo usually package pre releases also. Next release is on 22.
[18:47] <seb128> slytherin: ok, we will probably do the updates then
[18:48] <seb128> slytherin: slomo sent some mail to say he was away, I'm not sure about the details now but he should be back in the next days if I remember correctly
[18:49] <slytherin> seb128: My only concern is this bug as it blocks dvd playback completely.
[18:49] <slytherin> bug #260765
[18:50] <seb128> slytherin: it'll be fixed before intrepid if there a patch upstream no worry
[18:50] <slytherin> :-)
[18:50] <slytherin> I thought fixing it before beta freeze would be nice. :-D
[19:04] <mathiaz> seb128: cjwatson: I'm trying to fix bug 268838 - hence my question about python-gobject and python-central.
[19:05] <mathiaz> Another option could be to use dpkg triggers to run landscape-config after python-support trigger.
[19:05] <mathiaz> Would this be considered a good option ?
[19:08] <cjwatson> dendrobates: soren's right in general, although it does depend on exactly what you're trying to do
[19:08] <cjwatson> dendrobates: blacklisting is usually the wrong answer ...
[19:09] <cjwatson> mathiaz: ew. um, I don't know whether triggers are ordered by dependency. In principle they shouldn't need to be.
[19:09] <cjwatson> mathiaz: I don't think that will work reliably, sorry
[19:10] <dendrobates> cjwatson: I am just looking for a solution to the jre-headless problem and the fact that minimal now pulls in dbus and X11 libs.
[19:10] <cjwatson> dendrobates: if you try to use the blacklist for that, you'll remove dbus and X libraries from the Ubuntu desktop.
[19:10] <mathiaz> cjwatson: right - another solution would be to use Pre-Depends - but as you've already mentionned on friday it's not the most suitable solution.
[19:11] <dendrobates> cjwatson: works for me  :)
[19:11] <cjwatson> if there's no other way round it, a Pre-Depends could work in your case
[19:11] <cjwatson> but you should file a bug about it saying that the need for it should be fixed
[19:11] <mathiaz> cjwatson: so if fixing python-support or switching python-gobject to python-central, I'm running out of options.
[19:11] <mathiaz> cjwatson: python-central *is not possible*
[19:14] <cjwatson> use a Pre-Depends and swallow the pain, I guess
[19:24] <slytherin> does anyone have any idea why OOo build is failing again in powerpc?
[19:25] <calc> hmm networkmanager apparently doesn't like wep too much
[19:25] <calc> or else my intel wifi doesn't like it :\
[19:25] <slytherin> calc: probably latter. I never had problem with nm and wep
[19:27] <james_w> http://www.michaeldehaan.net/?p=718
[19:28] <johanbr> WEP is just broken. There's no way of telling which password/authentication method combination the AP wants.
[19:29] <slangasek> calc: no problems here, iwl3945; what are you seeing?
[19:30] <calc> i'm using iwl3945 and its been hard to get connected with hex code wep
[19:30] <calc> but it finally came back up i thought i was going to have to install intrepid to get it to work
[19:30] <nxvl> james_w: looks cool
[19:30] <calc> i'm running hardy with all updates
[19:30] <slangasek> james_w: so he NIH'ed FAI, and now wants to replace it? :)
[19:30] <james_w> looks like it :-)
[19:31] <james_w> I remember someone looking at it, but can't remember who
[19:31] <slangasek> calc: oh, hardy; that's like, old
[19:31] <james_w> server team I think, so that may have been a better place
[19:31] <nxvl> i remember to saw that name before, nothing else
[19:31] <nxvl> :D
[19:32]  * slangasek wonders if the guy understands Debian well enough to even evaluate whether it's a replacement for FAI
[19:32] <calc> slangasek: well it supposed to be LTS ;-)
[19:32] <calc> so hopefully will work
[19:32] <nxvl> slangasek: i won't bet
[19:32] <calc> lol
[19:33] <nxvl> rpm and deb based distros are quite different (actually way different) but there is still people thinking it's not
[19:34] <slangasek> calc: yes, but you're an Ubuntu developer, one would think you'd have tested whether the LTS worked on your system before it was released instead of 5 months after ;-P
[19:37] <calc> slangasek: well i don't use WEP except when i'm evacuated to davidm's house ;-)
[19:37] <slangasek> heh :)
[19:40] <superm1> slangasek, could you queue another DVD livefs build log?  the CD ones are finally building again, and we haven't had a functional DVD since the 2nd or so
[19:45] <calc> i don't think i even have enough diskspace to build OOo on my poor little laptop
[19:45] <calc> i'll have to free up space to do it
[19:52] <slangasek> superm1: I'm working on getting right-sized liveCDs first; I can queue a DVD livefs build after
[19:52] <superm1> slangasek, okay great thanks
[19:57] <calc> is there anything special i need to load to get usb->sata to see partitions
[19:58] <calc> i hooked my desktop 1tb drive up and it sees it but doesn't show partitions, etc
[20:01] <slangasek> you said "it sees it" - what sees it?
[20:03] <calc> i'll pastebine
[20:04] <calc> http://pastebin.ubuntu.com/47210/
[20:05] <calc> it does that then never shows the partitions, etc
[20:14] <torkel> nxvl: we are using a bissare mix of kickstart and FAI to install on of our clusters running CentOS. Not anything I would recommend though...
[20:20] <slangasek> calc: hmm, strange; normally the kernel should spit out the partition list right after that, so I don't know what's wrong
[20:20] <slytherin> is anyone already working on getting bluez 4.x in intrepid? Fedora 10 is going to have it.
[20:20] <slangasek> somehow it thinks it's a scsi generic device?
[20:23] <calc> maybe the device is too dumb to handle 1tb drive
[20:32] <slytherin> superm1: I will see if I can create some test packages.
[20:38] <calc> doh!
[20:38] <calc> i know why it doesn't work
[20:39] <calc> it sometimes helps to turn on the power
[20:39] <calc> hmm this power bar doesn't appear to work at all
[20:39] <mathiaz> kirkland: which component in the installer is responsible for asking the landscape question ?
[20:40] <cjwatson> mathiaz: pkgsel
[20:41] <mathiaz> cjwatson: great ! thanks.
[20:42] <cjwatson> mathiaz: anything particular about it?
[20:42] <mathiaz> cjwatson: I was trying to figure out if the landscape-client was installed
[20:42] <cjwatson> elif [ "$RET" = landscape ]; then
[20:42] <cjwatson>         echo 'landscape-client landscape-client/register_system boolean true' | \
[20:42] <cjwatson>                 log-output -t pkgsel chroot /target debconf-set-selections || \
[20:42] <mathiaz> cjwatson: IIUC only the question is asked and then the debconf entry is set correclty."
[20:42] <cjwatson>                 true
[20:42] <cjwatson>         apt-install landscape-client || true
[20:43] <cjwatson> fi
[20:43] <cjwatson> you remember incorrectly. :)
[20:43] <mathiaz> cjwatson: ok.
[20:43] <cjwatson> err, U => understand
[20:44] <calc> thats the first time i've tried a broken power strip
[20:45] <kirkland> mathiaz: sorry, cjwatson beat me to it
[20:46] <nxvl> seb128: can you point me to a doc or something on how to add something to gnome-session from CLI?
[20:46] <nxvl> seb128: or a man page on the topic
[20:46] <seb128> nxvl: to gnome-session? what do you mean?
[20:47] <nxvl> seb128: i mean, i want to launch a program at session start
[20:47] <seb128> nxvl: that's for a package or an user setting?
[20:47] <nxvl> seb128: and i want to add it from a script, not from menu->system->admin->session and such
[20:47] <nxvl> seb128: user setting
[20:47] <nxvl> can be a package aswell
[20:47] <nxvl> i din't really mind to package it
[20:47] <nxvl> :D
[20:47] <seb128> nxvl: ls /etc/xdg/autostart
[20:47] <nxvl> mmm
[20:48] <nxvl> seb128: thank you!
[20:48]  * nxvl HUGS seb128 
[20:48] <seb128> you're welcome
[20:48] <calc> now it works... after adding power
[20:48] <seb128> you can have autostart in the user .config directory too
[20:55] <lool> doko: Hmm I had python-ctypes installed on a system, presumably pulled by an old package and never forced away, it doesn't get autoremoved as many packages dep on python >= 2.5 | python-ctypes; it seems to break ctypes at the moment as there's a version check between python's ctypes and ctypes'
[20:55] <lool> doko: Do you think we should patch the version or let python >= 2.5 break python-ctypes to force its removal?
[20:57] <mathiaz> radix: you last patch for bug 268352 is the same as the previous AFAICT.
[20:59] <doko> lool: well, we should have a python2.4-ctypes,
[21:00] <lool> uh how come i saw it with 2.5??
[21:00] <lool> Python-Version: 2.4
[21:01] <lool> I just removed the package some minutes ago as the deps allowed it (only autoremove wouldn't catch it)
[21:01]  * lool wonders whether autoremove should try to remove some group of packages to see whether the deps are still satisfied by other installed ones
[21:02] <lool> And mvo disconnects muarf
[21:05]  * sebner asks himself if lool gets a lot of highlighting ^^
[21:11] <lool> sebner: I do
[21:11] <sebner> lool: doesn't it disturb you?
[21:12] <lunartear> anyone having issues with lwresd listening on 127.0.0.1:953 which breaks control communcation between rndc and bind?
[21:12] <Treenaks> lunartear: why are you running lwresd AND bind?
[21:12] <lunartear> thats what im wondering
[21:12]  * pitti waves
[21:13] <lunartear> does lwresd come with base or what
[21:14] <sebner> huhu pitti :D
[21:14] <lool> doko: So for some reason, my /usr/lib/python2.5/ctypes/__init__.py had version 1.0.2; now that I have removed and reinstalled python-ctypes, it's 1.0.3 and I don't get version mismatch anymore (it's python2.5's ctypes)
[21:15] <geser> Hi pitti
[21:15] <sebner> pitti: what person do I have to annoy to get information about upstart 0.5 -> intrepid?
[21:15] <lool> I wonder how this could happen, perhaps an intermittent python-cetrnal bug; this system was installed under hardy so no 2.4 -> 2.5 upgrade
[21:16] <pitti> sebner: upstart is Keybuk's baby, but he is sick ATM
[21:16] <pitti> hi geser
[21:16] <lool> sebner: upstart dev is mostly done by Keybuk I think, and last time I heard about it it wasn't finished for intrepid
[21:16] <lool> So it's jaunty material
[21:16] <sebner> pitti, lool : Thx for the info :D just saw that 0.5 is out since august
[21:28] <radix> mathiaz: sorry, missed your message earlier
[21:28] <radix> looking now
[21:29] <radix> mathiaz: the last patch puts the wrapper script into debian/ instead of into scripts/
[21:29] <radix> so that it doesn't affect non-debian/ directories
[21:44] <lool> slangasek: Hey can I grab you for a sec?  pigment-python is depwait on all arches because libpigment0.3-dev was installed into universe instead of main; could you promote libpigment0.3-dev to main?  It was in main in hardy, I don't really know why it was demoted; I think it was a typo when libpigment changed SONAME
[21:49] <alex-weej> question
[21:50] <alex-weej> sabdfl's blog about packaging in bzr... does that mean we can branch, pull changes from Ubuntu, pull remaining changes from upstream AND maintain our own changes?
[21:50] <Treenaks> alex-weej: if you know your bzr-fu :)
[21:50] <alex-weej> awesome!
[21:51] <alex-weej> i don't like jhbuild
[21:51] <alex-weej> i'd like to have a bleeding edge environment with Ubuntu tools
[21:52] <james_w> alex-weej: you will be able to eventually, but not in Jaunty.
[21:53] <alex-weej> james_w: what's coming in Jaunty then?
[21:53] <james_w> alex-weej: for jaunty there will only be Ubuntu history, we will then work on adding the rest later
[21:53] <alex-weej> ok
[21:53] <alex-weej> i was thinking it would be sane to just pull from upstream's RCS, forget about packaging history
[21:54] <alex-weej> but if you have some kind of plan to merge the two, rather you than me!
[21:55] <james_w> alex-weej: yeah, the details of merging them are still a bit hazy, for me at least, but we've got a while before we can implement it
[21:58] <alex-weej> ok cool
[21:59]  * hardwire does a little dance
[22:08] <Laney> How does the bzr stuff work for packages we merge from Debian? Surely then we'll only get one monolithic "debian+upstream" change?
[22:08] <Laney> Actually I guess you can separate out orig.tar.gz and diff.gz changes
[22:10] <ScottK> Laney: There's a long spec on the proposed change.  I suggest search the wiki. (I don't recall the url).
[22:10] <james_w> Laney: yeah, when Debian changes are integrated then you will be able to get diff upstream->debian and diff upstream+debian->ubuntu
[22:10]  * Laney has seen it
[22:10] <Laney> james_w: That's what I wanted to know, nice!
[22:11] <james_w> Laney: and obviously any other combination of diff that you want, upstream->ubuntu etc.
[22:11] <Laney> sexy
[22:17] <_me_> j #kernel
[22:21] <Adri2000> slangasek: if you've read my email about vsftpd on ubuntu-server@, what is your release manager opinion? I've got no answer from server people on the ml so far, so I'm asking you directly :)
[22:41] <slangasek> Adri2000: I'm not subscribed to ubuntu-server
[22:42] <slangasek> lool: libpigment0.3-dev, libpigment0.3-5 promoted
[22:42] <Adri2000> slangasek: https://lists.ubuntu.com/archives/ubuntu-server/2008-September/002231.html
[22:42] <lool> slangasek: thanks
[22:42] <calc> http://photos-e.ak.facebook.com/photos-ak-snc1/v312/15/64/34406965/n34406965_33948748_6629.jpg <- lovely picture of a power pole
[22:43] <calc> no wonder its going to take 4-6 weeks to get power back
[22:43] <lool> slangasek: How long til I give back pigment-python?  next hour?
[22:44] <slangasek> lool: is it not simply dep-wait?
[22:44] <NCommander>  DktrKranz BAH
[22:44] <lool> Oh right, it will figure itself
[22:44] <NCommander> DktrKranz: there you are, I haven't seen you on in ages
[22:44] <lool> slangasek: it is yes, nm
[22:45] <lool> NCommander: I thought you were typing your password on IRC
[22:45] <NCommander> lool: no, I'll never type iloveftbfs onto IRC :-)
[22:45]  * NCommander runs
[22:47] <NCommander> DktrKranz: https://bugs.edge.launchpad.net/ubuntu/+source/asis/+bug/268260
[22:47] <DktrKranz> NCommander, indeed! Mostly busy with new boss and working far away from home. I hope to have more time now
[22:47] <NCommander> DktrKranz: I made your work easy in bug form
[22:47] <NCommander> (although its not a fun bug)
[22:48] <slangasek> Adri2000: it's my opinion that ftps is fairly niche, so a fix for that needs to be balanced against the risk of any other changes included; it doesn't look too bad from 1000 feet up, anyway
[22:49] <DktrKranz> NCommander, it's a shame LP is so unfair with stable relase tasks on bugs with several packages affected
[22:50] <NCommander> DktrKranz: well, please upload to proposed :-)
[22:50] <DktrKranz> oh... so many packages, weren't only six or seven?
[22:51] <NCommander> I removed the build-dep
[22:51] <NCommander> There may be some that aren't needed
[22:51] <NCommander> (these were all the ones I had and tested)
[22:51] <DktrKranz> in https://wiki.ubuntu.org/HardyGnatTransition, I gave a little list of pacakges which could be affected
[22:52] <DktrKranz> most of them don't need to be fixed at a first glance
[22:52] <Adri2000> slangasek: ok, I'll try to get server people's opinions (maybe during the meeting tomorrow, though it will be difficult for me to attend), and if they agree, I'll file the FFe request
[22:55] <Adri2000> DktrKranz: hi, may I ask you to re-check the ngircd sru please? I had to upload .2 to fix another bug discovered by norsetto
[22:56] <DktrKranz> Adri2000, I'm leaving right now, could you please subscribe me to it?
[22:56] <DktrKranz> so I can have a look tomorrow
[22:56] <Adri2000> DktrKranz: sure, thanks
[22:57]  * DktrKranz moves to bed
[22:57] <Adri2000> night
[23:10] <jelmer> ScottK: Thanks for looking into the FTBFS for Samba4 and OpenChange
[23:10] <jelmer> ScottK, I didn't have a lot of time to dedicate to this in the last few weeks.