[00:17] <TheMuso> yay, new pulse released.
[00:17]  * TheMuso will prepare, but will wait till after the alpha.
[00:17] <TheMuso> Before uploading.
[00:32] <stgraber> fta: yeah, I'll likely release 0.11.1 soon with the bug fixes, then sync again once it reaches Debian
[00:49] <Keybuk> cjwatson: maybe we should work through that file at the sprint
[00:49] <Keybuk> many of its assumptions are wrong these days
[00:50] <Keybuk> ie. you don't need to be a member of cdrom, audio, etc. to have access to those anymore
[01:52]  * Keybuk amuses at Lennart
[01:52] <Keybuk> What a choice.
[01:52] <Keybuk> Uh? You can ship both if you wish and pass the decision what to use to
[01:52] <Keybuk> the user. I mean, that is the usual way Debian solves problems like
[01:52] <Keybuk> this, isn't it?
[01:53]  * RAOF tries to guess context.  Hm... pulseaudio+libcanberra?
[01:54] <Keybuk> pulseaudio
[01:54] <Keybuk> it's GNOME Module Inclusion week
[01:55] <RAOF> Ah, of course. But why would we ship two pulseaudios?
[01:55] <directhex> RAOF, because the farce of linux sound servers isn't QUITE complete
[01:56] <RAOF> Heh.
[01:56] <directhex> RAOF, just you wait for three versions of aRts and seven of ESD!
[01:57] <pochu_> RAOF: it's about the gnome-volume-control panel applet
[01:58] <pochu_> it's been rewritten for PA, and the discussion was about dropping the GstMixer version
[01:59] <RAOF> Ah.  Right.  Yeah, the new mixer looks like it's knocked some of the edges off pulseaudio integration.
[01:59] <RAOF> Why doesn't the applet detect a running pulse instance and change behaviour appropriately?  I thought that was an obvious requirement of such an applet.
[02:00] <pochu_> it's not an applet anymore. Now it's a tray icon
[02:00] <pochu_> http://mail.gnome.org/archives/desktop-devel-list/2009-January/msg00211.html would be the one
[02:01]  * pochu_ is off to bed, g'night everyone
[02:01] <RAOF> Oh, right.  I didn't notice the notification-applet/panel applet distinction.  Urgh.
[02:16]  * Keybuk is utterly baffled
[02:16] <Keybuk> this package clearly uses dh_installudev
[02:16] <Keybuk> but I cannot see where it calls it from :-/
[02:16] <Keybuk> ah, "dh binary-arch"
[02:57] <ebroder> Is it reasonable to assume that buildd chroots have a kernel installed?
[02:58] <TheMuso> ebroder: not afaik.
[02:58] <TheMuso> The most you would need kernel wise are kernel headers.
[02:58] <TheMuso> c
[02:58] <ebroder> Is there some way I can build-depend on linux-image-$(uname -r)?
[02:59] <RAOF> Why do you need to?  It's probably wrong. :)
[02:59] <ebroder> I have a site package I'm working on that build-depends on multipath-tools. multipath-tools' preinst runs modprobe, which tries to read from /lib/modules/$(uname -r)/, which I don't have
[03:00] <RAOF> Oooh.  Awkward.
[03:05] <ebroder> Hmm...it was apparently introduced in an Ubuntu change
[03:05] <toresbe> Hey, I've got a question out of personal curiosity. I'm currently dist-upgrading into jaunty, and I get this text in some of my upgrades...
[03:05] <toresbe> Setting up adduser (3.110ubuntu2) ...
[03:05] <toresbe> Xlib:  extension "RANDR" missing on display ":0.0".
[03:06] <toresbe> Xlib:  extension "RANDR" missing on display ":0.0".
[03:06] <toresbe> I thought it odd that this operation loaded xlib.
[03:06] <TheMuso> ebroder: What version of ubuntu?
[03:06] <TheMuso> ebroder: That really should be protected with a check I guess.
[03:07] <RAOF> toresbe: That's strange.  Why would adduser/preinst/postinst be calling anything X related?
[03:07] <ebroder> TheMuso: I'm using the version in Hardy. I don't know if it's still around
[03:07] <RAOF> Hah!  That's why.
[03:07] <RAOF> toresbe: Do you happen to have set your debconf frontend to something X-y?
[03:08] <TheMuso> ebroder: Ok, I am not sure if its changed since.
[03:08] <ebroder> One sec...I'll look
[03:08] <toresbe> RAOF: Ahhh. Well, I'm taking the "update-manager -d" route; I suppose it's done it for me. That explains it, of course.
[03:09] <RAOF> toresbe: Entirely possibly; it would probably want to present debconf questions with the gnome interface.
[03:09] <toresbe> It does indeed, IIRC.
[03:09] <ebroder> TheMuso: Looks like it's gotten wrapped in a useful check
[03:09] <toresbe> RAOF: I just had a hunch that it might be some accidental invocation that devs would be interested in, but that makes perfect sense.
[03:13]  * toresbe sods off. 
[03:30] <RAOF> Hm.  Any X guys in here, who would like to make xserver-xorg-video-nouveau actually installable for Alpha 3?
[03:50] <yao_ziyuan> ubuntu should use deja vu 10 as default font
[03:50] <yao_ziyuan> like kubuntu.
[03:51] <yao_ziyuan> it's much clearer
[03:52] <TheMuso> RAOF: How is it uninstallable?
[03:52] <RAOF> TheMuso: It needs the kernel modules before it'll do anything.
[03:52] <TheMuso> RAOF: ah
[03:53] <RAOF> So it depends on the linux-nouveau-modules virtual package, which is provided by nouveau-kernel-source, which has been on crimsun's review list forever. He's a busy man, so I'm advertising more widely :)
[03:58] <TheMuso> RAOF: I guess that needs DKMSing.
[03:58] <RAOF> It is.
[03:59] <RAOF> It's all ready to go, and sitting on revu awaiting ack.
[03:59] <TheMuso> Oh ok.
[05:01] <mathiaz> I've been trying to sort out the libmysqlclien15-dev issue in jaunty. The mysql-dfsg-5.1 upload produced a transitional package libmysqlclient15-dev which depends on the libmysqlclient-dev package from 5.1 (which is libmysql16).
[05:02] <mathiaz> since MySQL 5.1 is in universe, this breaks builds in main that depends on libmysqlclient15-dev.
[05:03] <mathiaz> so my plan is to upload a new mysql-5.1 src package that won't build libmysqlclient15-dev anymore
[05:03] <mathiaz> and upload a nochange pkg of mysql-5.0 so that libmysqlclient15-dev is again available in main.
[05:04] <mathiaz> does this seem correct ^^?
[05:04] <mathiaz> and should I wait for mysql-5.1 to have built and been published before uploading mysql-5.0?
[05:05] <ScottK> mathiaz: What -dev package will mysql 5.1 provide then?
[05:05] <mathiaz> ScottK: libmysqlclient16-dev
[05:05] <ScottK> OK.
[05:07] <mathiaz> after the upload there should be two binary packages (libmysqlclient15-dev from 5.0 in main and libmysqlclient16-dev from 5.1 in universe) both providing libmysqlclient-dev
[05:08] <ScottK> Ah.
[05:08] <mathiaz> according to apt-cache rdepends there are only one package that depends on libmysqlclient-dev: libgmyth-dev
[05:08] <ScottK> vorian: ^^^^
[05:08] <persia> TheMuso, Is there a bzr branch for jaunty pulse?  I see one for intrepid pulse, but wanted to submit a change for jaunty (Recommends: gnome-audio | ubuntu-sounds).
[05:09] <ScottK> mathiaz: amarok 2.0 also.
[05:09] <mathiaz> ScottK: is that already in the jaunty archive?
[05:09] <ScottK> And that one wants 5.1, so it ought to be changed to libmysqlclient16-dev
[05:09] <ScottK> mathiaz: Yes.
[05:09] <ScottK> Uploaded earlier today.
[05:09] <vorian> ohmy
[05:09] <ScottK> There's work to do to trim down how much of mysql it drags in, but it's there.
[05:10] <ScottK> vorian did it.  That's why I dragged him over here.
[05:10] <mathiaz> did it build?
[05:10] <ScottK> Yep and has lots of happy users.
[05:10] <TheMuso> persia: Yes. I am currently preparing 0.9.14
[05:10] <mathiaz> oh I see - it's in universe
[05:11] <ScottK> yes.
[05:11] <TheMuso> persia: And shoudln't that be the other way around?
[05:11] <ScottK> For now ...
[05:11] <TheMuso> persia: I can drop the change in if you like, what package needs that recommends?
[05:11] <ScottK> mathiaz: That's part of the reason to try and strip it down, to see if we can get it in Main without dragging all of 5.1 with it.
[05:11] <TheMuso> persia: I won't be uploading before the alpha freeze anyway, since its a biggish change that may rock the boat a little too much this far out from the alpha freeze.
[05:12] <persia> TheMuso, pulseaudio-module-x11 needs to Recommend: gnome-audio | ubuntu-sounds.  It currently only recommends gnome-audio.  ubuntu-sounds has a conflict on gnome-audio.  This breaks image builds for things that want both pulseaudio-module-x11 and ubuntu-sounds if universe is enabled.
[05:13] <TheMuso> persia: Ok. I'll make that change locally now, and it will go into the next upload, straight after alpha.
[05:13] <persia> Well, breaks Alpha for me, as I can't construct images.  Mind if just this gets pushed earlier?
[05:14] <mathiaz> ScottK: ok. But first we need to fix the archive. For now ooo doesn't build because of that.
[05:15] <ScottK> mathiaz: Absolutely.
[05:15] <TheMuso> persia: Sure, I can do that.
[05:15] <persia> TheMuso, Thank you.
[05:15] <mathiaz> so by uploading 5.1 that doesn't provide a libmysqlclient15-dev package and then reuploading 5.0, we should get back a correct libmysqlclient15-dev package.
[05:16] <mathiaz> Do I need to use an epoch in the mysql-5.0 upload?
[05:16] <ScottK> You don't want to do that.
[05:16] <ScottK> Then we'd always have a higher version than Debian.
[05:16] <mathiaz> ScottK: right.
[05:17] <persia> Ubuntu-local epochs should be avoided at nearly any cost.
[05:17] <ScottK> You'll need to do some version~realllyversion crap.
[05:17] <ScottK> Yep.
[05:17] <mathiaz> ScottK: right.
[05:18] <TheMuso> persia: Done./
[05:19] <persia> TheMuso, Thanks again.
[05:19] <mathiaz> so the current version for libmysqlclient15-dev is 5.1.30-2ubuntu1
[05:19] <TheMuso> persia: np
[05:19] <mathiaz> and I need to get it to 5.0.75
[05:20] <ScottK> 5.1.30really5.0.75-0ubuntu1 or convince Debian to do an epoch.
[05:20] <mathiaz> so I'd have to upload mysql-dsfg-5.0_5.1.30-2ubuntu2~really5.0.75-1ubuntu2?
[05:20] <ScottK> Not quite.
[05:21] <ScottK> mysql-dsfg-5.0_5.1.30really5.0.75-0ubuntu1 will do it, I think, but I'm also tired and it's been a long day.
[05:21]  * ScottK asks persia or TheMuso to consider it.
[05:21] <mathiaz> mysql-dfsg-5.0 is already at 5.0.75-1ubuntu1
[05:22] <ScottK> 5.1.30really5.0.75-0ubuntu1 is higher than that.
[05:22] <mathiaz> ScottK: hm right. version is hight than revision.
[05:22] <ScottK> You need to get a libmysqlclient15-dev version higher than you have now.
[05:23] <persia> mathiaz, dpkg --compare-versions is your guide to success.
[05:25] <mathiaz> hm - other option: considering that libmysqlclient15-dev has only been at 5.1.30-2ubuntu1 for a few days, could an upload of mysql-5.0_5.0.75-1ubuntu2 be possible? or soyuz wouldn't allow it?
[05:26] <ScottK> Soyuz is like an elephant.  It never forgets.
[05:26] <persia> mathiaz, Soyuz doesn't matter: consider that users may have downloaded the newer version, or mirrors, etc.
[05:26] <ScottK> With that, I'm off to bed.
[05:26] <ScottK> Good luck getting it sorted mathiaz.  These things are never pleasant.
[05:27] <mathiaz> persia: right - OTOH it's only in the development version.
[05:27] <persia> mathiaz, You just need to select some version that is greater than 5.1.30 yet accurately describes the state.  Appending really${real-version} is the common way to do this.
[05:27] <persia> mathiaz, Doesn't matter: do you really want to go and make sure *every* mirror of jaunty, public and private, didn't break?
[05:28] <persia> (Actually, just mirrors of Packages: including local apt-caches worldwide)
[05:30] <mathiaz> persia: hm - I see your point.
[05:30] <persia> mathiaz, That the archive software protects you by making sure you upload a safely newer version is a precious feature :)
[05:31] <ScottK> Since 5.0 will always be < 5.1, my suggestion is do a really version for now and then nicely ask Debian mysql maintainers if they'll do an epoch.
[05:31] <persia> Anyway, I fully support 5.1.30really5.0.75-0ubuntu1 as your best option.
[05:31] <mathiaz> persia: yes. That's the best option (and only option) it seems.
[05:31] <mathiaz> ScottK: persia: thanks for your input.
[05:32] <ScottK> mathiaz: You're welcome.  Note that you'd need 5.0 and 5.1 on the same epoch ....
[05:33] <mathiaz> ScottK: they're two different *source* packages.
[05:33] <ScottK> mathiaz: Yes, but you want the libmysqlclient-dev package in 5.1 to have a higher version than the one in the 5.0 package.
[05:34] <ScottK> If 5.0 is epoch'ed and the 5.1 is not, then it'll be backwards.
[05:34]  * ScottK really goes to bed.
[05:34] <persia> mathiaz, Do raise this issue with Debian: Debian's 5.1.30-2 also provides libmysqlclient15-dev, and so Debian may have reason to epoch.  Alternately, there may be some other solution planned that makes more sense.
[05:35] <mathiaz> persia: right - Debian 5.1.30 provides libmysqlclient15-dev as a transitional package.
[05:35] <mathiaz> persia: in 5.1.30 libmysqlclient-dev is the pkg that ships the dev files.
[05:35] <persia> mathiaz, Right, so the key is to determine the details for the transition plan in Debian, and develop a solution that works there.  Either with an epoch, or something else.  Then we can inherit it.
[05:35] <mathiaz> persia: in 4.1 and 5.0 libmysqlclient-dev was just a virtual package
[05:36] <persia> There's more flexibility in Debian, because epochs are (slightly) less painful.
[05:36] <mathiaz> persia: ok - how does that play with the fact that we need to fix Ubuntu ASAP?
[05:37] <persia> mathiaz, Well, it depends.  My experience with Debian maintainers is that the majority are happy to share details of a plan, if you're planing to execute it: saves labor.
[05:37] <mathiaz> persia: should we wait on the Debian discussion before doing anything in Ubuntu or should we proceed with fixing Ubuntu before alpha3?
[05:37] <persia> If the Maintainer is especially slow, then maybe it's worth something else, but I suspect the solution is already documented, and just needs someone to chase it.
[05:38] <mathiaz> persia: hm. I think I'll send an email to the Debian maintainer - he is usually very responsive.
[05:38] <persia> mathiaz, Personally, I'd suggest trying to catch the MySQL maintainers on OFTC, and asking if they have time now.  If not, then explain the *really* plan, and ask if that won't break too much as a quick-fix while offering to help with the bigger transition.
[05:38] <persia> email works too :)
[05:41] <mathiaz> persia: ok - well. It's too late here. We'll discuss this during tomorrow's server team meeting.
[05:41] <mathiaz> persia: thanks for your help and have a nice day!
[05:42] <persia> mathiaz, Sleep well.
[06:02] <calc> there appears to be too many people in my neighborhood with wifi now after christmas, i had to switch channels because there was too much interference between my laptop and my ap 2 feet away
[06:02] <calc> i can see at least 19 AP from my desk
[06:04] <LaserJock> calc: that's quite a few
[06:05] <calc> LaserJock: yea, i might have to switch to N if it gets any worse, heh
[06:05] <LaserJock> calc: any of them open APs?
[06:06] <calc> i hope the nm-applet can scroll for small displays it almost takes up my whole 1280x800
[06:06] <calc> 3 out of 19 appear to be open
[06:10] <tritium> Hey there, LaserJock.
[06:10] <LaserJock> tritium: holy cow dude, how are you?
[06:11] <tritium> LaserJock: great, thanks.  How are you?  Done with school?
[06:11] <LaserJock> ... almost
[06:11] <LaserJock> :(
[06:11] <LaserJock> getting there
[06:11] <tritium> Good!  Hang in there.
[06:11] <LaserJock> trying to weather the economy a bit
[06:11] <LaserJock> academic jobs are going in the toliet
[06:12] <tritium> Yeah?
[06:13] <LaserJock> yeah, my state is really bad
[06:13] <LaserJock> thank goodness I want to leave :-)
[06:13] <tritium> Best of luck to you!
[06:13] <LaserJock> we're looking at least 25% budget cuts
[06:14] <LaserJock> tritium: you still at Sandia?
[06:14] <tritium> LaserJock: yes
[06:20] <siretart> asac: the sunbird package seems to be broken. I've built it on intrepid. when I start it the very first time I get an 'BadWindow (invalid Window parameter)' error, and subsequent calls report an XUL error (unknown entitiy). :(
[06:20] <tritium> LaserJock: it's good to see you again.  I haven't spent much time in -devel or -motu lately.  Give me a /query one of these days, and we'll catch up.
[06:21] <LaserJock> tritium: for sure
[06:22] <tritium> Good night!
[06:23] <siretart> asac: it seems the old locale packages break sunbird 0.9. A the package needs a break. I'll file a bug
[08:35] <asac> siretart: bad window is strange ... but well ;). please subscribe me. otherwise it can take a while ;)
[09:25] <dholbach> good morning
[09:30] <ArneGoetje> cjwatson: we only need the language-pack-LL packages rebuilt, right? So, I change the version number to 1:8.04+20090105.1 ?
[09:44] <cjwatson> Keybuk: users-and-groups> yeah, I think that would be a good idea
[09:47] <cjwatson> ArneGoetje: right, or 20090113 if that's easier
[10:27] <liw> mvo, I'm trying to upgrade a VM from intrepid to jaunty, using "do-release-upgrade -d", it fails telling me I have held packages that it wants to upgrade
[10:27] <liw> mvo, could it tell me what?
[10:28] <liw> mvo, and what's the state in "dpkg --get-selections '*'" output I should look for? "hold" does not occur, but there's a bunch marked as "deinstall"
[10:28] <mvo> liw: yes, could you please put the log (/var/log/dist-upgrade/main.log somewhere)?
[10:28] <mvo> liw: I will add a better error message
[10:28] <ogra> james_w, aww, classmate-tools shuld probably just be dropped from the archive :)
[10:29] <ogra> (it reiles on functionallity only i810 can provide)
[10:29] <james_w> ogra: I wasn't sure, so I thought I would remove the NBS item first
[10:29] <liw> mvo, http://files.liw.fi/temp/jauntu-upgrade-main.log
[10:29] <james_w> you did have an alternative on -vesa :-)
[10:30] <ogra> yes, but thats not doing what it did anymore either
[10:30] <liw> mvo, so next I need to figure out what to do to get the upgrade working... suggestions? or is it too early to use do-release-upgrade and apt-get dist-upgrade would work better?
[10:31] <soren> liw: --get-selections only shows hold, if you've manually, explitly put the packages on hold.
[10:32] <soren> dpkg might hold back packages for other reasons (versioned package relationships, for instance)
[10:32] <ogra> james_w, the prob is that panning isnt supported at all anymore by the xserver so it doesnt matter which driver you use, the Virtual directive will always define a virtual desktop you cant pan over (classmate-tools was a panning mechanism)
[10:32]  * soren boards a plane
[10:32] <soren> brb
[10:33] <asac> zul: can you take a look at bug 286119 ... someone said that there are no new samba packages in the PPA?
[10:33] <james_w> ogra: are you going to file for removal then?
[10:33] <ogra> yes
[10:33] <james_w> cool, thanks
[10:35] <asac> ArneGoetje: can you look at the last comment of bug 288529?
[10:36] <asac> what do you think?
[10:37] <mvo> liw: hm, it seems to be a issue with your language-pack, could you upload the apt.log too?
[10:37] <mvo> liw: it should be possible to do upgrade with the tool, but it will refuse to upgrade if e.g. translations must be removed during the upgrade
[10:38] <mvo> liw: its a savety net feature, but this particular problem should be sorted for alpha-3
[10:38] <ogra> Keybuk, your rpm upload looks like it was wasted time ... ftbfs on all arches (i know lool is having a fixed version anyway that will go to debian though)
[10:39] <liw> mvo, http://files.liw.fi/temp/jauntu-upgrade-apt.log
[10:40] <mvo> liw: it seems like openoffice.org-voikko is the culprit, let me check further
[10:40] <DexterLB> hello
[10:40] <DexterLB> I have a few questions about becoming an ubuntero. Can I ask them here?
[10:40]  * mvo vaguely remember that caused trouble the last time around too
[10:41] <liw> Mirv, voikko mentioned :)
[10:41] <DexterLB> I want to activate a PPA
[10:41] <DexterLB> but to do that I must sign the code of conduct
[10:42] <DexterLB> but does signing the code of conduct add any obligations I must follow?
[10:43] <liw> DexterLB, above and beyong the obligation of behaving like a decent human being? not really, but please read it throughly
[10:43] <mvo> liw: yep, openoffice.org-voikko conflicts with openoffice.org-core (>= 2.4.1)
[10:43] <DexterLB> i read it three times
[10:43] <mvo> liw: is Mirv upstream for this?
[10:43] <liw> mvo, Mirv is involved with that package, not sure if he's upstream, too
[10:43] <liw> mvo, so if I remove -voikko, it should work?
[10:43] <mvo> liw: yes
[10:44] <liw> mvo, trying that
[10:44] <mvo> liw: if you could report a bug that would be most appreciated too (if removing voikko works)
[10:44] <mvo> liw: thanks
[10:44] <cjwatson> I doubt you could be sued for a violation of the code of conduct. It's there to remind people of a minimum standard of civilised behaviour, and to provide a basis for cancelling accounts if people persistently violate it.
[10:44] <cjwatson> (essentially)
[10:45] <liw> interesting, removing openoffice.org-voikko restarted gdm
[10:45] <liw> possibly because language-support-fi was also removed?
[10:45] <mvo> liw: I think that is a language-pack thing
[10:45] <ogra> cool ... so you dont need to use the iniscript :)
[10:45] <ogra> *init
[10:47] <cjwatson> StevenK: I've turned ubuntu-umpc back on in cdimage/crontab, since it was disabled without an explanation; I'm guessing that was due to the libavcodec51-induced build failure?
[10:47] <cjwatson> StevenK: if it was you and you meant to disable it, please leave a comment explaining why
[10:47] <ogra> wasnt it renamed yet ?
[10:49] <Mirv> liw/mvo: I'm the maintainer in Debian, but not upstream. Since lenny isn't out, I haven't started packaging the new version of openoffice.org-voikko supporting OOo 3.0.
[10:50] <Mirv> if lenny takes much longer, I probably should
[10:50] <mvo> Mirv: how much work do you expect it to be? has a lot changed?
[10:51] <cjwatson> ogra: doesn't seem to have been
[10:51] <ogra> ah, well, StevenK's call ... but it should ...
[10:51] <DexterLB> tralalalalalala lalala lalala tralalalalalala lalala lalala
[10:51] <DexterLB> oops
[10:51] <DexterLB> sorry
[10:52] <DexterLB> "typing randomly to help gpg generate my openpgp key"
[10:52] <Mirv> mvo: not too much, all changes have already been discussed since it's in fedora already, it's just that it requires libvoikko 2.0 as well so that has to be updated too
[10:52] <Mirv> some careful tinkering and testing is all that should be needed
[10:52] <liw> speaking of renamings... I'm beginning to lean towards "computer janitor" as the new name for system-cleaner / cruft remover
[10:54] <StevenK> cjwatson: It was disabled since I'm working towards UNR, and ubuntu-umpc is gone. I have changes ready, I'm dealing with it.
[10:54] <StevenK> cjwatson: If you'd like to sanity check my changes on antimony, feel free.
[10:56] <cjwatson> StevenK: oh, ok
[10:56] <BUGabundo_work> liw -1 on that name
[10:56] <cjwatson> StevenK: go ahead and comment it back out and leave a comment
[10:56] <StevenK> Now that my machine has released the 1.2GB that WoW took up, I'll disable it.
[10:56] <liw> BUGabundo_work, why?
[10:57] <StevenK> cjwatson: Done.
[11:00] <cjwatson> StevenK: thanks
[11:01] <BUGabundo_work> liw "janitor" bahh
[11:01] <BUGabundo_work> I know I know, if I don't like, I should provide a better one
[11:01] <BUGabundo_work> but even when you emailed the list, I couldn't think of a better one!
[11:02] <liw> I don't have any bad connotations from "janitor"
[11:02] <BUGabundo_work> maybe a poll on brainstorm
[11:02] <BUGabundo_work> or in #ubuntu would give us the view from a NEW user
[11:04] <liw> hmm, network access to my VM which is upgrading to jaunty has dropped
[11:04] <liw> that's not a good thing
[11:08] <BUGabundo_work> liw I guess you gona need a sudo dpkg --configure -a
[11:09] <liw> network-manager got upgraded (at least partially), I wonder if that's what killed the network
[11:10] <BUGabundo_work> liw it could! shouldn't ... /me blames asac :)
[11:11] <asac> liw: yeah libnm-util1 was stuck in bin new
[11:12] <asac> liw: not sure what parts were upgraded for you though
[11:12] <asac> jsut libnm-glib0?
[11:12] <liw> asac, I can give you dpkg.log :)
[11:12] <asac> liw: no need to ;)
[11:12] <BUGabundo_work> asac: so I SHOUDNT upgrate today?
[11:13] <liw> asac, libnm-util0, libnm-glib0
[11:13] <asac> BUGabundo_work: wait a few more hours
[11:13]  * BUGabundo_work wispers : to late!
[11:13] <BUGabundo_work> I guess that's why I have to reboot blue thingys on my jaunty
[11:14] <asac> liw: libnm-util0 isnt in new package afaik
[11:14] <asac> liw: which version did you get?
[11:14]  * BUGabundo_work checking
[11:15] <liw> asac, your version numbers are huge... libnm-util0 0.7~~svn220081018t105859-0ubuntu1 0.7~~svn20081018t105859-0ubuntu2 says dpkg.log
[11:15] <liw> assuming I copied them correclty by hand
[11:15] <asac> liw: thats old ;)
[11:15] <siretart> lintian errors are fun: E: iceowl-dev: missing-dependency-on-libc needed by ./usr/lib/iceowl/obscure-tool and 6 others
[11:15] <asac> liw: nothing i uploaded recently
[11:16] <BUGabundo_work> I have svn 200081018
[11:16] <liw> bah, and now the screen went highly colorful and then completely black, and I can't do nothing
[11:16] <liw> possibly something like gdm got restarted
[11:16] <BUGabundo_work> but it seems my network broke too, while I was out!
[11:16] <asac> BUGabundo_work: yeah. thats the old version. not sure why liw upgraded just now to that old version that is there since November ;)
[11:16] <BUGabundo_work> I guess its time to reboot... TWO warnings about it, should make me take it a bit more serious
[11:17] <asac> 0.7-0ubuntu1 takes another few hours as rdepends have to catchup
[11:17] <BUGabundo_work> lets see how it turns after reboot!
[11:17] <liw> asac, hmm, unattended-upgrades doesn't seem to have kept the machine up to date
[11:17] <BUGabundo_work> thinky of format and install today!
[11:17] <asac> strange
[11:17] <liw> asac, which is probably why the old package got upgraded
[11:18] <asac> yeah
[11:18] <BUGabundo_work> got a disk to make FULL backup
[11:18] <asac> liw: the package you got doesnt have any known regressions over the ubuntu1 one
[11:18] <BUGabundo_work> brb
[11:18] <liw> oh dear, I haven't configured unattended-upgrades correctly
[11:20] <liw> I need to figure out a way to make sure all my VMs are configured the right way, wrt u-a and mta etc
[11:30] <liw> er, while upgrading the VM to current intrepid, apt wants to upgrade evolution-data-server-common and remove ekiga, and some evolution packages
[11:32] <cjwatson> argh, X EDID probing loop *again*
[11:32]  * cjwatson gets ready to shut world down for reboot
[11:35]  * lool fastens his seatbelt
[11:36] <ogra> do you exepct turbulences ?
[11:37] <lool> Well when cjwatson shuts down the world I expect some yeah
[11:37] <lool> But I should actually losen my belt as it's lunch time &
[11:38] <ogra> just wait for the stewardess :)
[11:43] <BUGabundo_work> back
[12:55] <tjaalton> can someone explain why the lpia builder doesn't pull linux-libc-dev even though libc6-dev depends on it?
[13:17] <mvo> liw: did you file a bug about the vokkio issue with the upgrade?
[13:20] <Behnam> Hello
[13:20] <Behnam> I'm looking for a package that would enable the function " gdk_x_error " for gdb
[13:20] <liw> mvo, no, that slipped my mind, I'll do that now
[13:20] <mvo> thanks liw
[13:20] <Behnam> I'm using Ubuntu 8.10 and using " GNU gdb 6.8-debian "
[13:24] <liw> mvo, #316754, please reassign to openoffice.org-voikko if you think that's more sensible
[13:26] <liw> mvo, in other news: the machine still has no network and gdm kills the console (no reaction to mouse, keyboard, ctrl-alt-fX; screen is black), so today does not seem to be a good day to ugprade at all
[13:28] <mvo> thanks liw
[13:29] <mvo> liw: upgrade> sounds like good timing for alpha-3 ;)
[13:51] <apw> does anyone know how PPA's decide which architectures to submit your source uploads to?
[13:52] <ion_> Doesn’t it submit ‘Architecture: all’ packages to all of them? :-)
[13:52] <StevenK> apw: i386, amd64 and lpia are the 3 arches that PPAs build for.
[13:52] <apw> and do they do that weather your source builds there or not?
[13:53] <cjwatson> if you need to restrict it, put "Architecture: <list of architectures>" in debian/control rather than "Architecture: any"
[13:53] <cjwatson> they might build but will at least fail quickly
[13:53] <cjwatson> and you shouldn't need to worry
[13:53] <ScottK> ion_: No.  Arch all means one package works for all archs, so it's just built on i386.
[13:53] <ion_> scottk: Sorry, brainfart.
[13:53] <apw> for something going later to the main repo i assume i need to care
[13:54] <ScottK> ion_: No trouble.  The arch all/any thing is not entirely intuitive.
[14:13] <cjwatson> apw: not really. if it fails to build on an architecture it wasn't meant to build on anyway, then no big deal
[14:14] <cjwatson> apw: we do have an override file that fine-tunes this stuff, but if you get the Architecture: line right in your source package, then the only effect of that override file will be to stop you getting a failed-to-build mail
[14:14] <Keybuk> it's a shame that the Architecture file doesn't actually stop the buildd from trying it in the first place ;)
[14:14] <apw> yeah a strange thing indeed
[14:15] <apw> fair enough as long as it breaking and i don't have to care, is the norm i can cope with that
[14:20] <maxb> The bit that stops buildds trying in the first place is the Packages-arch-specific file
[14:21] <Keybuk> I never understood why Daniel just copied that bit of Debian, and didn't set out to improve it
[14:21] <maxb> Which bit?
[14:22] <maxb> I think part of the problem is that not enough information is propagated into the .dsc files / Sources files
[14:23] <ScottK> Well currently it's 'improved' in that if any binary in a source package is listed not to build built for an arch, then the entire source package is skipped, so no binaries are built, but I suspect that's not the kind of improved Keybuk was thinking about.
[14:23] <maxb> That's a bug outright
[14:23] <maxb> But they're going to fix it
[14:25] <ScottK> maxb: When?
[14:26] <maxb> Well, I say that based on positive noises being made in the bug I filed. Don't think its milestoned, but its clearly being thought about
[14:27] <ScottK> maxb: Well it's a regression that's been sitting there almost a month.
[14:27] <ebroder> Once the buildds build a package, does it still have to be manually approved before it goes into the archive?
[14:28] <maxb> I think it depends on whether it's a new binary package name or not
[14:28] <ScottK> ebroder: The first time for a new binary package, yes.  After that, no.
[14:28] <cjwatson> yes, the original problem is certainly that the .dsc file doesn't give the necessary information to the buildd system
[14:28] <liw> ebroder, if it is a new source or binary package, yes; otherwise no
[14:28] <ebroder> What about backports?
[14:28] <ScottK> ebroder: If it's new to that release, then the binary still goes through New.
[14:28] <ebroder> The pyyaml backport for Hardy seems to have been sitting in NEW for several days now
[14:28] <cjwatson> ebroder: aside from the NEW thing people mention, that's never been necessary in Ubuntu; it's necessary in Debian because the buildd admins need to sign packages
[14:28] <ScottK> ebroder: That's not unusual.
[14:29] <ebroder> *shrug* Ok
[14:29] <cjwatson> for us, the buildds are on trusted systems in order that that isn't necessary
[14:29] <cjwatson> I've accepted pyyaml now
[14:29] <ebroder> Haha. Awesome - thanks :)
[14:29]  * ScottK waves some pyyaml at ebroder (I maintain it in Debian/Ubuntu).
[14:30] <maxb> Though if the debian buildd admin can't trust the buildd system, how can they reasonably sign the binaries?
[14:30] <cjwatson> maxb: wrong way round
[14:30] <cjwatson> and I mean the central buildd dispatch system, not the individual buildds
[14:30] <cjwatson> buildds need to upload packages to the archive, which needs to have some way to trust that they actually came from a genuine buildd
[14:30] <maxb> oh, right
[14:31] <cjwatson> in Debian, that's done by the buildd admin (a Debian developer) signing the .changes file
[14:31] <cjwatson> in Ubuntu, the buildds have a trusted path to the archive
[14:37] <ArneGoetje> cjwatson: uploading new hardy langpacks
[14:37] <cjwatson> great, thanks
[14:42]  * liw has running jaunty VM (without graphics, though)
[14:42]  * liw is happy
[14:44] <BUGabundo_work> liw even on a native machine you wouldn't have 3D
[14:53] <ArneGoetje> cjwatson: langpack upload finished.
[15:35] <BUGabundo_work> is anyone from bug 202512 here?
[15:38]  * apw wonders if any sponsors have a moment to look over something (pm-utils and apport changes) we wanted to get into alpha-3, on bug #316419
[15:41] <Keybuk> kirkland: though I would like to continue that conversation ;)
[15:41]  * apw slaps ubottu
[15:43] <BUGabundo_work> apw: it seems the bot is a bit slow
[15:43] <kirkland> Keybuk: sure thing, now, or when you're less occupied?
[15:43] <BUGabundo_work> or LP may be the cause
[15:43] <Keybuk> now is fine
[15:43] <apw> probabally the translations or something eating launchpad
[15:43] <Keybuk> I'm not sure what your feeling is
[15:43] <kirkland> Keybuk: sure
[15:43] <Keybuk> but from my POV, I think we should
[15:43] <Keybuk> where there's an LSB init header, make sure that it's correct for Ubuntu
[15:44] <Keybuk> where there isn't an LSB init header, but we change the install priority anyway, add one and suggest Debian do the same?
[15:44] <Keybuk> where there isn't an LSB init header, and we don't touch it, leave it and file a bug on Debian asking for one?
[15:44] <kirkland> Keybuk: the first part I absolutely agree with ... if an LSB init header is there, it should be correct.  that's really annoying when that's out of step with reality
[15:45] <Keybuk> the second one is based on update-rc.d actually processing init script headers now
[15:46] <kirkland> Keybuk: remind me of the value of the LSB init header to you... this is what upstart processes for backward compat, right?
[15:46] <Keybuk> not currently
[15:46] <Keybuk> right now, Upstart just runs the old sysv-rc script
[15:46] <Keybuk> *but* if we could process init script headers, things would be much better!
[15:47] <Keybuk> we could have a simple shim that registers all init scripts with headers as Upstart jobs directly
[15:47] <kirkland> Keybuk: okay, so looking forward, that would be valuable information for us
[15:47] <Keybuk> (#2 I'm thinking where we change a script from defaults to something else - we could leave it as defaults, and add the LSB header, and update-rc.d does the right thing)
[15:47] <Keybuk> yes
[15:48] <kirkland> Keybuk: and why is it more valuable to have this in each script, and writing all that info to a simple database (flat file, or some such, one line per init script, multiple elements per line)
[15:48] <kirkland> Keybuk: seems that would provide a cleaner "view" of your current system
[15:49] <Keybuk> err?
[15:49] <Keybuk> well, the reason it seems to be valuable to add the init headers is that they're an LSB standard and Debian appears to be embracing them
[15:49] <kirkland> Keybuk: (note that I've never given this deep though until now)
[15:49] <kirkland> Keybuk: ah, okay.  "standard".  that's fine, i won't argue with that
[15:50] <kirkland> Keybuk: okay, could dh_installinit be enhanced to generate/update the header?
[15:50] <Keybuk> that's an interesting question
[15:50] <kirkland> Keybuk: what bothers me most is the duplication of information
[15:50] <Keybuk> well
[15:50] <kirkland> Keybuk: when you want to change one thing, having to remember to change it in multiple places
[15:50] <Keybuk> the way it's supposed to work is that you *don't* give any arguments to dh_installinit
[15:50] <Keybuk> instead you have the LSB header
[15:50] <kirkland> Keybuk: that's mostly how they get out of sync, I would guess
[15:51] <kirkland> Keybuk: righto
[15:51] <Keybuk> if you don't give arguments, it will default to using the LSB header
[15:51] <kirkland> Keybuk: that part makes sens
[15:51] <Keybuk> so ideally no rules should give arguments to installinit, and instead they should all have headers
[15:52] <Keybuk> that should be easy for Debian to accept
[15:52] <kirkland> Keybuk: in what cases would we prefer provides args to dh_installint, versus editing the header properly
[15:52] <kirkland> Keybuk: i like your last suggestion;  that would probably benefit from a lintian check
[15:53] <Keybuk> I don't think there any situations where we should prefer arguments to dh_installinit
[15:53] <kirkland> Keybuk: W: dh_installinit-should-not-have-arguments: You should update the init script header according to the LSB specification
[15:53] <Keybuk> if there are arguments present, and we are changing them
[15:53] <Keybuk> I think it would be better to give Debian a patch to add an LSB header matching their arguments - and take them away
[15:53] <Keybuk> then patch the init script in Ubuntu to change the LSB header
[15:53] <Keybuk> update-rc.d also now complains if the init script has no LSB header
[15:53] <Keybuk> so a lintian double-whammy seems good to me ;)
[15:54] <kirkland> that sounds good
[15:54] <Keybuk> (some dh_installinit arguments like --name are ok)
[15:54] <kirkland> Keybuk: sure, the biggie are the ordering numbers
[15:57] <Keybuk> also, selfishly
[15:57] <Keybuk> if LSB init script headers are nicely standard
[15:57] <Keybuk> upstream will ship them
[15:58] <Keybuk> likewise if Upstart jobs are nicely standard
[15:58] <Keybuk> upstream will ship them
[15:58] <Keybuk> so it makes our diff-to-upstream less ;)  we just remove Debian patches to things
[15:59] <kirkland> Keybuk: right so the "standard" I'm going for with the status stuff would be *really* uniform, nice looking output to "service --status-all"
[16:00] <Keybuk> I'm hoping we'll start to see that with udev now; Ubuntu, RedHat/Fedora, SuSE and Gentoo all now share a common /lib/udev/rules.d directory with no local changes
[16:00] <kirkland> Keybuk: you can run that on an intrepid+ system, and see what services have status actions, and which don't
[16:00] <Keybuk> so upstream projects should start shipping udev rules by default, installing to the correct machine, etc.
[16:00] <kirkland> Keybuk: nice
[16:00] <ion_> Neat
[16:00] <Keybuk> of course, Debian refuses to join the club
[16:00] <ion_> Hehe
[16:00] <Keybuk> but that's ok, we just delete things from the Debian package - and fallback to upstream behaviour ;)
[16:02] <Nicke> <x
[16:02] <Nicke> oops
[16:03] <Riddell> zul: mysql 5.1 contains libmysqlclient15-dev
[16:03] <Riddell> zul: but mysql 5.0 also has that package
[16:03] <Riddell> and 5.0 is the one in main
[16:03] <zul> Riddell: yeah will be fixed today
[16:03] <Riddell> thanks
[16:03] <ScottK> Riddell: mathiaz and I discussed it last night.
[16:03] <Riddell> I'm sure I double checked that when I approved the package
[16:04] <ScottK> IIRC mysql-server or something similar is also a problem.
[16:04] <mathiaz> Riddell: I'll upload mysql-dfsg-5.0_5.1.30really5.0.75
[16:04] <mathiaz> Riddell: and mysql-dfsg-5.1 that doesn't build libmysqlclient15-dev.
[16:05] <mathiaz> Riddell: we'll discuss it in today's ubuntu-server meeting.
[16:05] <Riddell> mathiaz: why is the funny version needed?
[16:05] <ScottK> mathiaz: I think mysql-server too.
[16:05] <Riddell> oh, because the binary version is too large
[16:05] <calc> mathiaz: why the weird version number for 5.0.75 its still 5.0.75 in the archive currently?
[16:05] <mathiaz> Riddell: because currently libmysqlclient15-dev is at 5.1.30-2ubuntu1
[16:05] <calc> oh i see
[16:05] <Riddell> yeah
[16:06] <mathiaz> Riddell: either we use *really* or an epoch.
[16:07] <calc> yea the sooner that is fixed the better OOo still needs rebuilding in time for alpha3 :)
[16:11] <Joe_CoT> So, does anyone feel like being really nice and going through ubuntu-devel's moderated posts? :)
[16:11] <cjwatson> in progress
[16:12] <Joe_CoT> thanks
[16:12] <cjwatson> Joe_CoT: in future, please do not crosspost between -devel and -devel-discuss
[16:12] <cjwatson> Joe_CoT: crossposting between moderated and unmoderated lists produces very confusing results
[16:12] <cjwatson> particularly when those lists have similar purposes, save for the moderation bit
[16:13] <Joe_CoT> ok, i'll keep it in mind
[16:46] <arthur-> doko: there is a fix in Debian's glibc for BZ 9706, you maybe want to sync with it (it's any/local-nss-overflow.diff)
[17:00] <Keybuk> kirkland: randomly, do you think it would be worth a lintian warning for installing udev rules into the wrong place?
[17:06] <kirkland> Keybuk: not that I'm any authority on the matter, but I generally take lintian warnings pretty serious and find them helpful
[17:06] <Keybuk> we don't seem to have any patches to lintian right now though?
[17:07] <kirkland> Keybuk: right, i'd definitely that's best to push up through Debian
[17:07] <kirkland> Keybuk: i mean, we could carry it, but should be working lintian checks back upstream
[17:07] <Keybuk> the trouble is, Debian have a different policy
[17:08] <ScottK> lintian has a pretty decent idea of if an upload is aimed at Debian or Ubuntu, so distro specific tests are quite possible
[17:09] <Keybuk> how hard would it be to add an ubuntu-specific test that no package should ship a *.rules file under /etc/udev ?
[17:09] <ScottK> I'd guess not very.
[17:12] <Turl> hello, can you take a look at bug #285417?
[17:13]  * Keybuk can't see how it knows it's going for ubuntu
[17:17] <ScottK> Keybuk: http://launchpadlibrarian.net/19797997/lintian_2.0.0_2.0.0ubuntu1.diff.gz touches where it checks for the bad distro name (which is where is knows)
[17:17] <Keybuk> no
[17:17] <Keybuk> that checks debian/changelog
[17:18] <Keybuk> which means the lintian check would not happen for packages sync'd from Debian
[17:18] <ScottK> It may be that I was off my  rocker then.
[17:18] <Keybuk> this needs to happen for those too
[17:18] <ScottK> Upon further reflection, I think I was thinking about something in debchange, not lintian.  Sorry for the bother.
[17:19] <kirkland> Keybuk: it might be reasonable to modify Ubuntu's lintian to know that it's Ubuntu's lintian :-)
[17:19] <kirkland> lintuntu
[17:20] <ScottK> Currently there is no "Ubuntu's Lintian", which is a good thing.
[17:23] <LaserJock> it's a good thing ... until it's not :-)
[17:23] <Keybuk> scottK: but Ubuntu policy differs from Debian's
[17:23] <ScottK> Keybuk: True, so it'd be useful to have lintian understand the differences and which distro was targetted.
[17:24] <ScottK> The Debian Lintian maintainers, at least from the outside, seem open to Ubuntu specific requirements in the Debian package.
[17:24] <ScottK> Doesn't mean we need two Lintians.
[17:32] <cjwatson> send mail to debian-lint-maint@lists.debian.org - I'm quite sure they'd be happy to discuss it
[17:34] <NCommander> doko, ping
[17:38] <Notch-1> hi all
[17:40] <Notch-1> i have a "little" problem: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/292159
[17:41] <cjwatson> well, that certainly ain't a linux bug
[17:41] <cjwatson> oh, hm, well, the fact that it fails to configure is
[17:42] <Notch-1> ?
[17:42] <cjwatson> never mind me
[17:43] <Notch-1> ah ok :D but if you have something to say i'ìm sure can help...
[17:44] <cjwatson> evand: should USB sticks permit update-initramfs or not?
[17:45] <cjwatson> that's sort of separate from the fact that the kernel upgrade process fails with that stub in place
[17:45] <evand> I think they should
[17:45] <cjwatson> which is an interesting and somewhat difficult point, though
[17:45] <cjwatson> because if you don't run update-initramfs, you haven't really completed the kernel upgrade, and arguably it *should* fail
[17:46] <evand> indeed
[17:46] <cjwatson> does anything further need to be done in order to get an upgraded USB stick to boot the new kernel, though?
[17:47] <cjwatson> I mean, something would need to copy the kernel and initramfs out to the wrapper filesystem
[17:47] <Notch-1> yes
[17:48] <Notch-1> but that's not the problem, the problem is that the update fails, even if can successfully complete the update-initramfs...
[17:50] <evand> Perhaps we could try to remount /cdrom rw and attempt to write out the new kernel, should we detect that we're running from a live CD?
[17:52] <Notch-1> is that a problem? i would be very happy to copy by hand the kernel and the initrd...
[18:00] <cjwatson> Notch-1: it's the problem because we need to fix that in order that we can make the update succeed with a good conscience
[18:00] <cjwatson> Notch-1: I understand the bug report, I'm just thinking beyond the immediate problem
[18:00] <NCommander> kees, ping?
[18:01] <cjwatson> evand: I think it would have to be something like that
[18:01] <cjwatson> pretty horrible, but
[18:03] <cjwatson> evand: moved over to casper and assigned to you
[18:03] <Notch-1> thank you for the explaination cjwatson, i'll take care of the file substitution issue if you help me convince the developer to take a look and fix the update problem :PP
[18:03] <cjwatson> Notch-1: evand and I are the relevant developers :-P
[18:03] <evand> cjwatson: thanks, I'll give it a shot tonight
[18:04] <Notch-1> cjwatson: thanks a lot :D
[18:05] <cjwatson> Notch-1: you might know to copy the kernel and initrd by hand, particularly after having it explained to you, but an arbitrary user wouldn't know this and would be rather surprised to find that their USB stick refused to boot after an update
[18:05] <cjwatson> Notch-1: I think that's *worse* than an update failing
[18:05] <cjwatson> so I don't want to "fix" the problem only to cause something worse
[18:05] <Notch-1> yes yes, i was meaning that i'll take care of fix this part of the problem, if you solve the rest for me
[18:05] <cjwatson> Notch-1: which part of the problem?
[18:06] <Notch-1> the correct generation of the initrd ad the update failure
[18:06] <cjwatson> Notch-1: I'm not sure why we would solve half the problem and leave the rest to users :)
[18:07] <cjwatson> correct generation of the initrd is absolutely trivial to fix at the same time
[18:07] <Notch-1> i'm not telling this :P
[18:07] <cjwatson> indeed, it would be difficult to solve the real problem without fixing that
[18:07] <cjwatson> thanks for your offer, but I think we should be able to take care of the whole thing
[18:08] <Notch-1> jus trying to ease your work as i can
[18:09] <cjwatson> evand: we should have a think about how update-initramfs should work on a live CD too
[18:09] <evand> cjwatson: hrm, good point.  Noted.
[18:09] <Notch-1> so another question, are you guys Matt Zimmerman, Tollef Fog Heen or marco amadori? just curiosity...
[18:10] <cjwatson> evand: there's clearly no point in regenerating the initramfs there, but perhaps we should arrange for it not to fail updates in this way, since you're unlikely to be able to break live CD boot by means of an upgrade
[18:10] <cjwatson> Notch-1: use the /whois command in your IRC client
[18:10] <evand> right
[18:11] <cjwatson> Notch-1: also, the X problem you noted in a comment on that bug has nothing to do with the original bug report, and I recommend that you file it separately
[18:11] <Notch-1> you mean the repeated crashes?
[18:12] <cjwatson> yes
[18:12] <Notch-1> installing intrepid to hd ad upgrading it seems to work fine, i think it's already solved
[18:13] <Notch-1> it crashed just every couple hours, or when i play a video with vlc :D
[18:14] <Notch-1> only with livecd version it's very unstable...
[18:15] <Notch-1> btw i'm using kopete on debian etch so whis does not work very well :P
[18:16] <cjwatson> if you have an inadequate IRC client, you could use a better one - whois or equivalent is a pretty standard feature :-) It may be implemented in some other way, e.g. right-click and "user info" or something like that (I've never used kopete)
[18:17] <calc> kopete is an IM client which probably isn't very well suited for IRC
 utf8test is æ þ â ç ß £ ö ª ð õ ¡ ¿ é × 字 ☺ ⍥ ⪘ Ⱍ ‽ ♫ ♐
[18:17] <Notch-1> yes i'm just trying to switch to kubuntu to solve problems like this :D
[18:18] <Notch-1> anyway i was asking who you are because i read somewere that the maintainers of live-initramfs package decided to "let casper project die" in order to use live-initramfs... what can you tell me about this?
[18:18] <bluefoxicy>  ⪘ --> Ⱍ <-- the heck is this? 2C1D? ... ‽ ♫ ♐
[18:19] <Notch-1> calc: yes it's very badly implemented, i read very hostile comment on the project page.. and the kde4 version does not jet support irc, they still have to port it...
[18:19] <stdin> that's the hex representation of that character 0x2c1d
[18:20] <bluefoxicy> yeah, but it doesn't show in xchat-gnome, utf8 broked.
[18:20] <cjwatson> Notch-1: there was a period when casper was not very actively maintained in Ubuntu for various reasons; the people who dealt with casper in Debian had trouble getting through to us and therefore decided to fork
[18:20] <ion_> Nah, you just don’t have a font with the character.
[18:20] <Notch-1> cjwatson: whis function IS implemented in my version of kopete, but simply works 1 out of 10 times :D
[18:21] <cjwatson> Notch-1: we're getting back on top of things in Ubuntu now, and the casper project is most definitely not dead, but the live-initramfs fork has happened now and they are fairly determined to bad-mouth us
[18:21] <cjwatson> (as far as I can tell)
[18:21] <cjwatson> I would rather focus on improving casper than engage in a war of words
[18:21] <Notch-1> sure :D
[18:21] <Notch-1> i'm happy to ear this
[18:22] <cjwatson> and frankly, I prefer casper as a name to the rather dry "live-initramfs" name :)
[18:22] <Notch-1> so let's do this :D how can i help?
[18:22] <cjwatson> submit patches for open bugs
[18:22] <cjwatson> figure out where open bugs are actually due to some other package and not casper (this is common)
[18:22] <cjwatson> improve debugging documentation
[18:23] <cjwatson> figure out where we can correctly resynchronise casper with improvements made in live-initramfs
[18:23] <Notch-1> i think i can only do the third, but what else do you need ?
[18:24] <cjwatson> that's basically it
[18:24] <cjwatson> oh, testing of new changes obviously although since it's used on Ubuntu live CDs we're doing OK on that
[18:24] <cjwatson> but honestly, it's pretty hard work which is why it's taken a while
[18:24] <Notch-1> testing it's my second name :D
[18:25] <cjwatson> do please file clear, separated bug reports about separate issues, though
[18:25] <cjwatson> conflating multiple problems into a single bug report just makes things harder
[18:25] <NCommander> kees, when you get a chance: https://bugs.edge.launchpad.net/ubuntu/+source/shadow/+bug/316841
[18:25] <Notch-1> sure
[18:26] <Notch-1> you think is this the case?
[18:26] <cjwatson> is what the case?
[18:27] <Notch-1> this bug
[18:27] <cjwatson> your comment on it was certainly a different issue
[18:27] <cjwatson> too many of those and it really does get rather hard to untangle
[18:27] <Notch-1> can we split this bug to a more specific reports?
[18:28] <cjwatson> you can file your comment separately.
[18:28] <cjwatson> as I asked
[18:28] <cjwatson> it probably belongs on X
[18:28] <cjwatson> I mean https://bugs.launchpad.net/ubuntu/+source/casper/+bug/292159/comments/21, not the earlier one
[18:29] <Notch-1> yes but as i told you i think this one was already solved... i have some crashes even with uptodate version, but it seems very different so...
[18:30] <cjwatson> surely it is not solved if it is happening with a current live CD
[18:31] <cjwatson> just because you can't reproduce it by installing the system in a different way doesn't mean it doesn't exist, does it?
[18:31] <Notch-1> current livecd does not means NOTuptodate versions of all ?
[18:31] <cjwatson> I mean http://cdimage.ubuntu.com/daily-live/current/jaunty-desktop-i386.iso
[18:32] <Notch-1> ahhhhhhhh but i'm using intrepid :D
[18:32] <Notch-1> i should try :P
[18:33] <calc> cjwatson: sorry to interrupt but does the jaunty ext4 support defragging yet?
[18:33]  * calc has noticed some severe performance issues on his systems due to fragmentation and may switch over to that if it is er 'reliable' in jaunty timeframe
[18:34] <slangasek> oh geez, why have the ISOs gone OMGOversized the day of the milestone freeze?
[18:35] <calc> 795MB for i386, but not oversized on amd64, seems a little strange
[18:36] <cjwatson> calc: I don't think it has online defragmentation, but I was just dealing with integration and am not an expert in the filesystem itself
[18:36] <calc> cjwatson: ok
[18:36] <cjwatson> ext4.wiki.kernel.org is probably the place to look
[18:37] <kees> NCommander: looking
[18:37] <cjwatson> it seems to think that online defragmentation is planned for ext3 as well, FWIW
[18:37] <cjwatson> http://marc.info/?l=linux-fsdevel&m=116160640814410&w=2
[18:37] <cjwatson> hmm, that's from 2006
[18:37] <kees> NCommander: do you think that patch is valid for Debian too?
[18:38] <NCommander> kees, if Debian wants to support these boards, yes
[18:38] <slangasek> calc: because something pulled java onto the i386 image.  Was it you? :-)
[18:38] <calc> slangasek: uh i hope not
[18:39]  * NCommander thought OOo3 was still FTBFS
[18:39] <slangasek> java *and* fortran
[18:39] <calc> slangasek: this was the cycle that OOo went from 2.4.1 to 3.0.1 though
[18:39] <NCommander> That's impressive
[18:39] <NCommander> I didn't even know fortan was in main
[18:39] <slangasek> calc: this is a change just in the past 24h
[18:39] <kees> NCommander: can you open a Debian bug report for it too?  I'll upload your debdiff now, but it'd be nice to get that into Debian if they want it.
[18:39] <NCommander> kees, sure, although I don't expect it to move anytime soon
[18:40]  * NCommander checks who debootstrap's maintainer in Debian is
[18:40] <cjwatson> debian-boot inc. me
[18:40] <cjwatson> what's the problem?
[18:40] <NCommander> cjwatson, --foreign is fairly broken
[18:40] <cjwatson> not something I've often looked at
[18:41] <NCommander> cjwatson, two stage problem, 1. it doesn't set permissions correctly to allow boot into a foreign chroot
[18:41] <NCommander> (init doesn't end up +x)
[18:41] <NCommander> 2. the second stage script is completely broken
[18:41] <cjwatson> can you give me a quick recipe to reproduce it, to save me time?
[18:41] <calc> slangasek: is there a way to tell easily who pulled in java?
[18:42] <calc> slangasek: i can make a chroot and test its not OOo but not sure how to easily do it otherwise
[18:42] <Notch-1> excuse me http://cdimage.ubuntu.com/daily-live/current/jaunty-desktop-i386.iso is newer than the alpha 2 ?
[18:42] <slangasek> erm.  surely the correct perms on init should be shipped in the .deb?  How does --foreign screw that up?
[18:42] <cjwatson> Notch-1: yes, it's a daily build
[18:42] <NCommander> cjwatson, debootstrap --foreign --arch i386 should work. You can't boot the resulting chroot, and chrooting into it, and trying to run the second stage script dies
[18:42] <cjwatson> slangasek: that's what I was thinking ...
[18:42] <slangasek> calc: I'm working through testing here
[18:42] <calc> slangasek: since OOo is such a beast just eyeing its depends/recommends can be hard to figure out ;-)
[18:43] <cjwatson> Notch-1: alpha 2 is possibly more likely to actually work; daily builds are largely untested and can break for arbitrary reasons at any time
[18:43] <NCommander> slangasek, no idea, but I just know I don't get a bootable chroot, I'm looking more indepth at the problem now, since I need to make jaunty's userland be happy and smiling for ARM
[18:43] <slangasek> calc: best test case is apt, a wedge, and a hammer
[18:44] <cjwatson> $ sudo debootstrap --foreign --arch i386 jaunty ncommander-test http://riva/ubuntu
[18:44] <cjwatson> $ ls -l ncommander-test/sbin/init
[18:44] <cjwatson> -rwxr-xr-x 1 root root 104364 2008-09-30 00:52 ncommander-test/sbin/init
[18:44] <NCommander> Strange
[18:44] <slangasek> (i.e.: set up a chroot; reproduce the apt install line from the installer, confirming that it installs the stuff you don't want; specify a package to exclude by appending "$package-"; see what complains; iterate)
[18:44] <NCommander> Maybe it was a umask issue here
[18:44] <cjwatson> NCommander: noexec filesystem?
[18:44] <NCommander> however, that chroot will be unbootable *has tried a few times to do so*
[18:44] <slangasek> dpkg doesn't honor umask
[18:44] <calc> slangasek: ok
[18:44] <cjwatson> (though debootstrap is supposed to check for that)
[18:44] <NCommander> cjwatson, eh, dunno, I'm investigating
[18:45] <slangasek> and noexec doesn't prevent perms from being set, just prevents the files from being executed afterwards
[18:45] <cjwatson> yes
[18:45] <cjwatson> I'm happy to try to help but will need a better bug report :)
[18:45] <Notch-1> cjwatson: thanks, so i'll try both...
[18:45] <NCommander> cjwatson, can you try the second stage install script
[18:45]  * NCommander would like to get a bug out of this conversation
[18:47] <cjwatson> I can reproduce second-stage failure
[18:47] <NCommander> cjwatson, chroot into the new chroot, then run debootstrap/debootstrap
[18:47] <cjwatson> W: Failure trying to run: chroot / dpkg --force-depends --install
[18:47] <NCommander> yeah
[18:47] <cjwatson> you need to run /debootstrap/debootstrap --second-stage, for the record
[18:47] <slangasek> calc: openoffice.org-calc Depends: lp-solve?
[18:48] <NCommander> cjwatson, would be nice if that was documented somewhere ;-)
[18:48] <NCommander> although the impression I got was you just run that script to finish the setup
[18:48] <calc> slangasek: yes, but that doesn't appear to be pulling in java
[18:48] <calc> slangasek: still looking for why java is getting pulled in
[18:48] <slangasek> calc: no, but it's one of the things that's changed that's pulling in new deps
[18:49] <cjwatson> was documented in the first web page I found when googling for "debootstrap foreign" ;-)
[18:49] <mathiaz> slangasek: I've just uploaded two new versions of mysql-dfsg-{5.0,5.1} to fix the libmysqlclient15-dev package
[18:49] <NCommander> :-P
[18:49] <cjwatson> but yes, I'll document it
[18:50] <NCommander> cjwatson, what that output you got from using --second-stage?
[18:50] <cjwatson> NCommander: I quoted it above
[18:50] <mathiaz> calc: that should fix the ooo build failure you mentionned today.
[18:50] <calc> something in the OOo stack of depends seems to be pulling in the java but i can't find what
[18:50] <calc> mathiaz: thanks
[18:50] <mathiaz> calc: (or yesterday)
[18:50] <NCommander> cjwatson, just noting, it generates the same error if you omit second-stage
[18:50] <NCommander> cjwatson, does this mean I can file a bug now?
[18:50] <cjwatson> NCommander: BTW, look at the manual page for --foreign and read it in context; I don't think it's *that* undocumented, but will clarify
[18:51] <NCommander> fair enough
[18:51]  * NCommander is still trying to figure out if there is a bug, or user error here
[18:51] <cjwatson> NCommander: feel free to file one about the second stage not working, but the other problem should be separate if it's a bug at all
[18:51] <slangasek> calc: -core also has a new dependency on librdf0, which pulls in a *lot* of recommends
[18:51] <NCommander> cjwatson, i'll kick one into Debian, and then create an assiocated one in ubuntu since they have to be merged anyway
[18:52] <kees> slangasek: oh, are we frozen?  can I upload NCommander's securetty patch, or should I wait until Thu?
[18:52] <slangasek> calc: and also libmysqlclient15off and libpq5 as deps
[18:52] <NCommander> kees, I didn't think we entered freeze yet.
[18:52] <slangasek> kees: I'm not sure if we're frozen, or just vapor locked due to the CDs having suddenly exploded
[18:52] <kees> hah
[18:53] <calc> slangasek: librdf0 here pulls in 740KB of stuff?
[18:53] <kees> slangasek: so... upload?
[18:53] <slangasek> calc: and you think we had .7 MB to spare?
[18:54] <slangasek> kees: what's this "securetty patch"?
[18:54] <calc> gah i found the issue
[18:55] <calc> slangasek: perhaps we should just remove OOo from the cd entirely its continuing to grow as time progresses and we have been at the limit on the cd for several years at least?
[18:55] <calc> ure has a recommends on java2-runtime
[18:55] <cjwatson> I don't think removing OOo from the CD is going to be acceptable either
[18:55] <calc> java is very intertwined in OOo since Sun is upstream and it is just getting more that way as time goes on
[18:56] <NCommander> calc, there has to be a way to sheer some fat off OOo
[18:56] <calc> NCommander: yes fork it ;-)
[18:56] <NCommander> I was thinking diet but ...
[18:56] <NCommander> :-P
[18:56] <slangasek> removing it from the CD is going to leave us with a liveCD that doesn't let you work on any documents unless you use google docs
[18:57] <calc> NCommander: well we have in the past been making sure it doesn't actually install java but that breaks various bits of OOo and it seems to be increasing the amount it breaks as time goes on
[18:57] <kees> slangasek: http://launchpadlibrarian.net/21172354/shadow.debdiff
[18:57] <calc> slangasek: is there a way to tell how much just the java2-runtime takes on the cd?
[18:57] <kees> NCommander: btw, you might want to change your DEBEMAIL to be your @ubuntu address.  :)
[18:57] <calc> slangasek: also why doesn't think make the amd64 cd oversized as this isn't arch specific
[18:58] <calc> s/think/this/
[18:58] <slangasek> calc: because the amd64 livefs failed to build.
[18:58] <calc> slangasek: oh ok so its just the old one listed under current?
[18:58] <NCommander> kees, Actually, i was going to set it to my new @debian.org, since ATM, that's my more professional address aside from my work one
[18:58] <NCommander> ;-)
[18:59]  * NCommander is shot
[18:59] <slangasek> calc: by looking at the CD which is 95MB oversized, I would guesstimate that 92MB of that is due to the java+fortran stuff being pulled in
[18:59] <calc> slangasek: i can respin OOo again and bump the recommends down to a suggests if that is needed, or do you have a way to override it?
[18:59] <slangasek> calc: it needs a respin
[19:00] <calc> slangasek: ok will do
[19:00] <calc> should be done in around 2hr
[19:01] <slangasek> calc: ok.  which bits are you changing?  I want to have an idea of whether everything is getting dropped off that needs to be
[19:01] <calc> i was going to make it so that java2-runtime is no longer recommended
[19:01] <cjwatson> NCommander: if you haven't yet filed that debootstrap bug in Debian, please don't
[19:01] <calc> but as i notice that mysql is still broken i can't even install the build-deps atm
[19:01] <NCommander> I haven't
[19:01] <cjwatson> NCommander: it's specific to the Ubuntu scripts
[19:01] <NCommander> cjwatson, oops
[19:01] <cjwatson> NCommander: so please file it in Ubuntu (or I could just fix it now ...)
[19:01] <NCommander> cjwatson, the later is preferable ;-)
[19:02] <slangasek> kees: pah, why does Freescale need its own serial port naming convention?
[19:02] <slangasek> kees: but yes, ok to upload
[19:02] <kees> slangasek: ask NCommander :)
[19:02] <NCommander> slangasek, ask freescale
[19:02]  * calc looks at the mysql build process
[19:02] <slangasek> NCommander: freescale didn't submit the patch. :)
[19:02] <cjwatson> it's due to r50373 changing scripts/debian/sid but not the Ubuntu ones
[19:02] <NCommander> slangasek, freescale created the serial driver with the funky names
[19:03] <calc> mysql takes ~ 4hr to build and hasn't even started on all buildds yet :\
[19:04] <NCommander> cjwatson, I will investiage the --foreign doesn't generate bootable rootfs bugs
[19:04] <NCommander> Although it might not be something that is fixable
[19:04] <NCommander> s/not//g
[19:05] <slangasek> calc: lp-solve -> libsuitesparse-3.1.0 is also what pulls in fortran, which we also don't have room for.  Can lp-solve be dropped to a suggests?
[19:06] <calc> slangasek: ok i'll take a look
[19:06] <calc> ah i can install the build-dep i just had to add universe to my chroot
[19:06] <NCommander> kees, please tell me when shadow is uploaded so I can officially tick it off the TODO list
[19:09] <kevku> what happened with kdebase-runtime 4:4.1.96-0ubuntu1 amd64? :(
[19:10] <slangasek> calc: what about the possibility of filing bugs about the known ways OOo breaks without java, and sending out a call for help?  Is there a problem of upstream migrating existing functionality over to java, or is it mainly a problem of not cleanly separating the java bits?
[19:10] <slangasek> kevku: nothing, except that it hasn't built yet?
[19:11] <kees> NCommander: it's uploaded
[19:11] <mathiaz> calc: if you enable universe in your chroots, you'll pull in libmysqlclient-dev from mysql-5.1 (which will be libmysqlclient16-dev)
[19:11] <calc> slangasek: both and also extensions can use java but if a user tries to install one they won't necessarily know it uses java and it just won't work
[19:12] <calc> mathiaz: yes but it will work well enough to generate a source package :)
[19:13] <calc> mathiaz: actually iirc it currently (before the new build finishes) pulls in libmysqlclient15-dev -> libmysqlclient-dev -> libmysqlclient16-dev  or something like that
[19:14] <mathiaz> calc: libmysqlclient15-dev -> libmysqlclient-dev
[19:14] <mathiaz> calc: libmysqlclient16-dev doesn't exist for now.
[19:15] <slangasek> calc: heh, there are OOo extensions?  I've never heard of those
[19:17] <calc> slangasek: yea lots of them
[19:17] <calc> slangasek: http://extensions.services.openoffice.org/
[19:18] <calc> slangasek: so we probably need a standing comment in release notes for users to install the openoffice.org meta package if they intend to actually use it for more than basic tasks
[19:19] <cjwatson> NCommander: --second-stage breakage fixed in debootstrap 1.0.10ubuntu2, just uploaded
[19:19] <slangasek> calc: I don't think we should word it that way ("more than basic tasks"), but yes, I agree
[19:20] <calc> slangasek: well i defer that to someone more adept at writing release notes :)
[19:20] <calc> but yes basically lots of things will break in various weird ways with how much we have pared down OOo for the cd
[19:21] <calc> now that we managed to squeeze math into the cd it helps resolve some of the more ugly issues of document corruption
[19:21] <slangasek> well, I think the document corruption bug is still a bug in its own right that should be fixed
[19:22] <slangasek> anyway - do bugs get filed in LP as we run into things that break in weird ways?
[19:22] <calc> yea it probably should refuse to open the document if it doesn't know how to due to missing bits (at minimum if not also suggest what you need to open it)
[19:22] <slangasek> even if we don't have the capacity to fix them, I think it's important to have them documented
[19:22] <calc> yes
[19:22] <slangasek> ok, good
[19:23] <slangasek> hmm, the test case for the math document corruption bug shows OOo able to *open* the document fine without -math installed
[19:23] <slangasek> it just corrupts it on save
[19:23] <slangasek> ("just")
[19:25] <calc> yea :(
[19:25]  * NCommander hugs cjwatson 
[19:33]  * calc does note that lpsolve was a depends not a recommends, so hopefully it doesn't just explode
[19:34] <slangasek> calc: it's a new depends, though - why was it added?
[19:34]  * calc hopes his repackaging of OOo for split build will help resolve some of these issues with too much on the cd
[19:34] <calc> slangasek: it was an internal library copy before but with work on getting rid of those it became an external dependency
[19:35] <calc> with the split build in jaunty+1 there will no longer be any internal copies or anything (afaik anyway)
[19:35] <slangasek> hmm, I guess today was the first CD build that had OOo 3 available for inclusion, so the dependency could've been added for any number of reasons :)
[19:35] <calc> heh yea
[19:35] <slangasek> calc: but the internal library copy before didn't require libsuitesparse...?
[19:35] <slangasek> or fortran
[19:36] <calc> not quite sure how it worked before, maybe lp-solve's need of those things isn't as high as its dependency suggests, i don't know
[19:38] <calc> slangasek: do any of the openoffice.org-help-* packages land on the cd?
[19:38] <slangasek> calc: help-en-gb, help-en-us
[19:39] <calc> they also pull in java
[19:39] <slangasek> yuck
[19:39] <calc> and aiui they don't work at all without java, i will have to ask someone to verify quickly
[19:39] <slangasek> that's like, the opposite of help
[19:39] <slangasek> fwiw, the package only Recommends: openoffice.org-java-common, doesn't Depend: on it
[19:40] <calc> oh oops i misread it
[19:40] <calc> i had heard something about them needing it but it must not be that important :)
[19:40] <slangasek> still, the Recommends will be a problem in practice
[19:40] <calc> hmm but we install recommends by default so heh
[19:41] <calc> i suppose i can drop them down to suggests as well and see if anyone screams :)
[19:45] <calc> ugh that also means i need to respin l10n as well
[19:45] <calc> oh well :)
[19:47] <calc> generating the sources now for upload
[19:48] <slangasek> calc: thanks
[19:55] <calc> slangasek: should be done uploading in around 75m
[19:55] <slangasek> ok
[20:21] <ScottK> slangasek: Are we frozen for Alpha 3 yet?
[20:22] <slangasek> ScottK: please consider us slushy; the freeze announcement should go out within the hour
[20:22] <ScottK> slangasek: I'll run it by you then ...
[20:23] <ScottK> slangasek: We've discovered there is some abi breakage in the libplasma3 that we uploaded with KDE 4.2 RC1 yesterday that make at least some packages that use it crashy if not rebuilt.
[20:24] <slangasek> doh
[20:24] <ScottK> slangasek: With the exception of compiz, all the stuff in Main is done.  I'd like to do a no change compiz upload.
[20:24] <slangasek> yeah, go for it
[20:24] <ScottK> OK.
[20:25] <ScottK> slangasek: Done.  That was pretty high on the list of packages I figured I'd never upload.
[20:25] <slangasek> heh :-)
[20:26] <pochu> ScottK: but now you're TIA! :P Luckily for you it will be touched again before next round of merges ;)
[20:27] <cjwatson> YM TIL?
[20:27]  * pochu is no longer TIA for Eclipse. thanks asac! :P
[20:27] <pochu> err, yes
[20:27] <ScottK> Interestingly enough, I can't push my changes to the bzr repo because I'm not a compiz packager.
[20:27] <cjwatson> slangasek: (I just uploaded a merge of vim to hopefully fix that messy diversions upgrade bug, BTW)
[20:29] <slangasek> ok
[20:30] <ScottK> RAOF or MacSlow: I just did a no change compiz upload.  I'd appreciate it if one of you would update debian/changelog in bzr (I can't).
[20:30] <RAOF> Ah, it's compiz team owned.
[20:35] <Amaranth> so...is xulrunner broken right now?
[20:40] <ScottK> RAOF: Yes and I'm not on that team.  LP seems to think you are.
[20:41] <RAOF> I am, yes.  I'll merge your update in there.
[20:42] <ScottK> RAOF: Thanks.
[20:58] <slangasek> er, who changed the channel mode?
[21:00] <slangasek> cjwatson, Hobbsee, Mithrandir, Keybuk: could someone mark 'freeze' in the topic, please? (And possibly change the channel mode back)
[21:01] <ion_> A few days ago, someone kept spamming the topic. That’s probably when the +t was set.
[21:09] <cjwatson> I think we can live without the +t for a while
[21:15] <Nafallo> \o/
[21:17] <tilgovi> I'd like to help test jaunty, but I only have one laptop at my disposal. Anyone have thoughts on how stable jaunty would be on my machine? My guess is that I'd be fine, given I have intel graphics and no strange components to speak of
[21:17] <tilgovi> basically...is jaunty unusable at this point, or should I view it as a "probably works, but at your own risk"
[21:19] <ScottK> tilgovi: Even if it works right now, there's no guarantee it wouldn't be horribly broken tomorrow.
[21:19] <tilgovi> ScottK, yeah...I suppose that's true.
[21:19] <ScottK> If you aren't prepared to deal with that, don't install it on real hardware.
[21:19] <tilgovi> heh
[21:20]  * ScottK is not kidding.
[21:20] <tilgovi> I might very well be prepared to deal with that. I'll have to think about it more though.
[21:20] <ScottK> Think VM in the mean time.
[21:20] <tilgovi> Alright, thought about it more. Not going on my production box yet.
[21:21] <tilgovi> I think it's getting to be about time I got another hard drive for all the vms I always want to play with.
[21:21] <calc> crap my uploads failed :(
[21:22] <calc> i should not have done them simultaneously it timed out my router :\
[21:23] <superm1> slangasek, i just uploaded an xfce4-session that otherwise would have prevented an alpha3 for xubuntu and mythbuntu.  hope it's okay since i just saw the archive freeze  notice 10 min ago on /t as i was uploading..
[21:23] <superm1> cody-somerville, ^
[21:30] <james_w> Keybuk: is it possible to make autoreconf work when using just autoconf and libtool, and not automake?
[21:31] <Keybuk> james_w: it should
[21:33] <james_w> Keybuk: you have to have an aclocal.m4, otherwise it tries to run aclocal. Is that reasonable?
[21:33] <james_w> There appears to be a clash between not using automake, and having custom macros in .m4 files.
[21:34] <james_w> if I install automake and let it run aclocal, then it doesn't gather the extra macros, because I don't have a Makefile.am for it to take ACLOCAL_AMFLAGS from.
[21:35] <james_w> so autoreconf calls autoconf with no -I, so it ignores the extra macros, and it all falls to pieces from there
[21:37] <kees> why is there yahooapis.com JS in the LP html?
[21:38] <ion_> Why not? YUI is neat.
[21:39] <kees> because I like my JS coming from single domains.  :)
[21:43] <kees> ion_: ah, ha.  bug 316509
[21:46] <ion_> LP could always use a local copy of YUI, but i don’t mind sites using it from the origin.
[21:47] <RainCT> cjwatson, kees: so, who of you should I vote? ;P
[21:48] <Turl> hello
[21:49] <Keybuk> james_w: sure, aclocal is part of automake ;)
[21:49] <Turl> may you see https://bugs.launchpad.net/bugs/285417 ? There are debdiffs to fix the packages, so it should be an easy task
[21:49] <cjwatson> RainCT: me! or him!
[21:50] <cjwatson> HTH
[21:50] <RainCT> hehe
[21:51] <james_w> Keybuk: ok, so I create an aclocal.m4 containing all the things I need by hand, but how do I get the libtool stuff in without hardcoding the path to libtool's m4?
[21:53] <Keybuk> james_w: include lines?
[21:53] <Keybuk> usual way to make aclocal is m4 directory, copy things in, and put include lines in aclocal.m4
[21:54] <james_w> m4_include([m4/libtool.m4])
[21:54] <james_w> etc?
[22:02] <Keybuk> james_w: yeah
[22:02] <Keybuk> (aclocal should really move to autoconf)
[22:03] <james_w> k, thanks Keybuk, I'll give it a go
[22:08] <kees> RainCT: I promise to bring even more crazy compiler flags to Ubuntu.  but... I'd do that anyway.  :)
[22:09] <RainCT> \o/
[22:11] <TheMuso> bryce: re alsamixer -c0, I am either going to write a wrapper script to force that when pulseaudio is running, or change something in the alsamixer code, probably the former, since its less painless.
[22:12] <bryce> TheMuso: ok
[22:13] <bryce> TheMuso: yeah, I had kind of a painful upgrade experience this morning until I ran across using the -c0 flag
[22:14] <bryce> TheMuso: on the plus side I cleaned up a bunch of dupe/related bug reports on sound problems with this hardware
[22:15] <TheMuso> bryce: I saw, I am going to see if there is already a git commit upstream for your hardware. If not, I'll push your patch upstream and push it to the kernel guys.
[22:16] <bryce> excellent, thanks
[22:21] <MacSlow> ScottK, I can't ... I don't have upload-rights
[22:21]  * MacSlow is not a MOTU
[22:21] <ScottK> MacSlow: You do for that bzr branch, but RAOF already took care of it.
[22:21] <slangasek> superm1: ack, fixes for showstoppers are implicitly ok :)
[22:21] <TheMuso> bryce: Am I right in guessing that the patch you attached to 210865 is for more than one chipset? If so, I wonder if better names should be used, rather than 82801H.
[22:22] <geubank4> 4777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777uiiiiiiiiiiiiiiiiii
[22:22] <TheMuso> geubank4: Stuck keyboard?
[22:23] <slangasek> I'd guess 'cat'
[22:23] <geubank4> Darn cat
[22:23] <MacSlow> ScottK, ah ok ... sorry just came back from capoeira
[22:23] <ScottK> MacSlow: No trouble.
[22:23] <bryce> TheMuso: I can't confirm that but suspect it may be the case
[22:23] <TheMuso> Ok.
[22:24] <bryce> TheMuso: one thing to check is if 0x8227 covers more than just 82801H, that those other chips are valid having the mitac quirk applied for them
[22:24] <TheMuso> bryce: Right.
[22:25] <TheMuso> bryce: Well there is no reference to 0x8227 in the hda code, so...
[22:25] <bryce> I *suspect* it to be the case in reading through other 82801* bug reports, but in too many cases the bug reports lacked necessary info/troubleshooting to be certain
[22:25] <TheMuso> However, I need to check another branch to be 100% sure of that.
[22:26] <wasabi> hmm. ebox was supported
[22:26] <wasabi> i thought ^
[22:26] <bryce> TheMuso: one thing is you could talk with ogasawara or one of the other kernel team people who have weekly concalls with Intel to give some feedback on this issue
[22:27] <ScottK> wasabi: #ubuntu-server for ebox.
[22:27] <TheMuso> bryce: ok, but its not an intel codec, its realtek, so one would think they should have this covered...
[22:27] <TheMuso> but anyway, I'll see what I can do with what we have now.
[22:27] <bryce> cool
[22:29]  * calc bbl grabbing early dinner
[22:42] <laprice> I was trying to look up info on building packages but http://ubuntuforums.org/ is 404
[22:43] <laprice> is there a standard reference doc?
[22:44] <vorian> laprice: https://wiki.ubuntu.com/PackagingGuide
[22:44] <laprice> Grazie
[22:48] <vorian> no problemo
[22:50] <Narugawa> good night peolpe
[22:51] <Narugawa> do u know if the alpha 3 release at night or day the 15 ?
[23:29] <NCommander> doko, I need your assistance with an ICE once your available.
[23:32] <jdstrand> soren: fyi-- with my latest commit to ufw, it won't interfere with libvirt (or anything else)
[23:32] <jdstrand> soren: it'll be in ufw 0.26
[23:34] <soren> jdstrand: Ooh! Neat!
[23:34] <jdstrand> soren: though it took me awhile, I did promise I wouldn't forget you :)
[23:35] <soren> You did indeed. I'm looking forward to see how you did it :)
[23:36] <jdstrand> soren: actually, I just make sure that I only touch ufw chains. It's long been a beef of slangasek's that it flushes the built-in chains. It was surprisingly tricky to get right, but it all seems to be working now :)
[23:36] <slangasek> \o/ :)
[23:36] <jdstrand> :)
[23:37] <soren> jdstrand: Yeah, I know it was tricky. I secretly took a stab at it long ago, failed horribly and chose not to tell anyone about it :)
[23:37] <StevenK> ... until now
[23:37] <jdstrand> heh :)
[23:38] <soren> It never took place.
[23:38]  * soren does the jedi hand waving trick frantically
[23:39]  * soren notes that it doesn't look very cool, calm, and jedi-like when done frantically
[23:39] <jdstrand> haha