[00:14] <mrz0g> evand
[02:38] <calc> seagate took their firmware fix offline to fix it
[02:38] <calc> seagate doesn't inspire confidence with not even being able to make their fix work, segfaults on trying to flash
[03:40] <nhandler> So when in the development cycle do we make update-manager's -d flag work?
[03:41] <raof> Should be working now; that's how I updated, pre alpha-1.
[03:42] <nhandler> raof: Well, when I updated pre-alpha 1, I went the update sources.list dist-upgrade approach. Now, I just did a fresh install of intrepid the other day. But update-manager -d doesn't show anything
[03:43] <bluesmoke> nhandler: it's sudo update-manager -c -d
[03:43] <bluesmoke> -c tells it to check for a distro upgrade, -d tells it to use a development one
[03:43] <raof> You could try adding a -p, to update using the update-manager from -proposed.  I'm not sure if there's one there yet.
[03:43] <bluesmoke> yeah, I always try to remember to do sudo update-manager -c -d -p
[03:43] <bluesmoke> usually forget the -p though :P
[03:46] <nhandler> No luck bluesmoke. It still says I am up-to-date
[03:47] <nhandler> This is interesting. In the terminal, it says "current dist not found in meta-release file
[04:36]  * calc understands a bit about this pulseaudio/mixer mess esp after reading all Realtek codecs are considered "buggy" :-\
[04:37] <TheMuso> calc: where did you read about the realtek stuff?
[04:40] <calc> the Gnome 2.26 module inclusion discussion heats up thread on desktop-devel-list@gnome.org
[04:40] <TheMuso> ah ok
[04:40] <calc> there is a link to a list of drivers that are broken wrt PA support
[04:40] <TheMuso> hrm interesting.
[04:40] <calc> and on that list is all snd-hda-intel realtek codecs
[04:40] <calc> so not every realtek codec but most of the modern ones anyway
[04:40] <TheMuso> interesting, since realtek is one of the most popular.,
[04:41] <calc> and if i read the page right all intel ac97 is broken as well
[04:41]  * TheMuso wonders whether they are broken in a hardware sense or software sense.
[04:41] <calc> driver sense afaict
[04:41] <TheMuso> Oh great.
[04:41] <calc> it seems they might need things like jack sensing support added (?)'
[04:41] <calc> apparently thats a new feature in alsa
[04:41]  * calc has no idea about that stuff
[04:42] <TheMuso> Yeah it is a new feature, jaunty won't likely have it.
[04:42] <calc> stuff was mentioned like the fact there are separate mixers for headphones vs speakers on laptops
[04:42] <TheMuso> yeah I've seen that.
[04:42] <calc> the thread is pretty long but there was some interesting stuff in it, seems to be all about PA
[04:43] <TheMuso> not on my own hardware, but I have heard of it
[04:43] <calc> mine has that
[04:43]  * TheMuso needs to read it.
[04:43] <calc> apparently the new PA stuff in 2.25 doesn't work well with it
[04:43] <calc> i'm still on 8.10 on my laptop
[04:43]  * TheMuso gets the thread URL
[04:43] <calc> i'm not surprised it probably has issues the new mixer app is so dumbed down i was surprised it could work at all
[04:43] <calc> http://mail.gnome.org/archives/desktop-devel-list/2009-January/msg00251.html
[04:44] <TheMuso> yeah i have it
[04:44] <calc> that isn't the beginning of it, just where i am in the thread currently
[04:44] <TheMuso> oh ok.
[04:44] <calc> it sounds cool in theory but i don't know that they can dumb down alsa well enough to have it 'just work'
[04:45] <calc> if they can do it sanely i will be impressed
[04:46] <TheMuso> And not forgetting different drivers for USB/other PCI cards also have different mixers.
[04:46] <calc> but then gnome seems to shoot for an 80% solution and leave the other 20% to use KDE ;-)
[04:46] <bluesmoke> TheMuso: I have jack sensing already
[04:46] <calc> TheMuso: yea thats how i noticed it works weird with my usb headset
[04:46] <bluesmoke> If I plug in headphones the speakers turn off but I can turn them back on with alsamixer
[04:47] <TheMuso> bluesmoke: Jack sensing is more than just that.
[04:47] <TheMuso> bluesmoke: It can detect what type of device is ocnnected, i.e speakers, headphones, microphone, etc.
[04:47] <bluesmoke> ah
[04:47] <calc> i might try upgrading to jaunty on my laptop and just deal with the breakage :)
[04:47] <bluesmoke> so it would turn on digital out automatically
[04:48] <dtchen> jaunty's kernel doesn't have that work, though
[04:48] <calc> yes that is useful but not letting the user turn it off isn't particularly great
[04:48] <raof> Hm.  Where's bugzilla for the new volume applet?  I'd like to check if some features already have bugs or not.
[04:48] <calc> eg if you have your system hooked up via hdmi to a tv does it always play out that interface since its hooked up?
[04:48] <calc> having good defaults with no way to override them... isn't good
[04:49] <calc> and having to go into the terminal isn't a real solution
[04:49]  * calc should be arguing this with the PA upstream not with poor Ubuntu maintainer ;-)
[04:49] <TheMuso> calc: PA itself has no UI, its other utilities that sit on top of PA that give the UI.
[04:51] <calc> TheMuso: ah well gnome-volume-control (or whatever the tray thing is)
[04:51] <TheMuso> calc: gnome-volume-manager, yeah thats GNOME stuff.
[04:51] <calc> ah ok
[04:51] <bluesmoke> gnome-volume-manager is utopia stuff, not sound
[04:51] <dtchen> raof: http://tinyurl.com/g-m-bugs
[04:52] <TheMuso> sorry gnome-volume-control is what I meant
[04:52] <raof> Urgh.  They're thinking of removing the applet entirely, leaving us with the crazy notification icon.
[04:52]  * raof thinks that's 100% pure UI crack.
[04:52] <calc> raof: yep and converting the old version to a notification icon as well
[04:53] <calc> raof: so they act the same for fallback
[04:53]  * raof presumes he's not the only one who's wierded out by a volume control icon that only turns up after something has started playing.
[04:54] <calc> heh
[04:54] <TheMuso> thats stupid I agree
[04:54]  * calc bbl
[04:54] <TheMuso> No other OS does that.
[04:58] <ScottK> TheMuso: It's innovation then.
[04:58] <TheMuso> ScottK: if you could call it that. I'll bet KDE has more sane plans. :)
[04:58] <ScottK> That's my impression.
[04:59] <dtchen> although I hear 4.2 has gained a PA backend for Phonon?
[04:59] <calc> well gnome is full of crack recently it seems, they broke gnome-session and didn't seem to care too much
[05:00] <ScottK> dtchen: I don't think we're using it though.
[05:01] <TheMuso> ScottK: Riddell has talked to me about possibly enabling it at least.
[05:01] <TheMuso> ScottK: I can't remember the exact conversation, and I'd have to ask him again what he was thinking as I don't entirely remember myself.
[05:01] <raof> I didn't think PA was a possible backend for Phonon.  Isn't phonon a GStreamer abstraction?
[05:02] <ScottK> I think it's meant to be more generic than that.
[05:02] <raof> But you say "play me this mp3 file", right?
[05:02] <ScottK> TheMuso: Providing it as an option is much different than here's the new default.
[05:02] <raof> I mean, I know it's more than a gstreamer abstraction, but it's a *media* abstraction, not a soundserver abstraction?
[05:02] <TheMuso> ScottK: I know
[05:03]  * raof has tried to understand, but *still* doesn't get what phonon buys KDE.
[05:03]  * ScottK thought it was sound, but has tried to avoid knowing much about it.
[05:04] <LaserJock> calc: I think full on crack, that's why I'm using KDE presently after years of Gnome usage
[05:07] <raof> Fun new volume control bug: have two audio devices, one set to full volume, the other one (which is actually playing audio) set to a much lower, comfortable value.
[05:08] <raof> Click the "Choose output device" radio button for the 100% volume device.  This results in the other, active device having its volume changed to 100%.  This is awkward when said other device is my USB speakers, which are painfully loud at that volume.
[05:08]  * TheMuso would try KDE if there was sufficient accessibility.
[05:09] <dtchen> raof: well, it's rather very WIP; stream migration isn't quite present
[05:09] <ScottK> TheMuso: Feedback on what's missing would be appreciated.
[05:10] <raof> dtchen: For values of "quite" equal to "at all", yes.
[05:10] <TheMuso> ScottK: Its got to do with frameworks etc. QT is not yet hooked up to the at-spi framework, and won't be till at-spi is on dbus. It will be a while yet.
[05:10] <TheMuso> ScottK: In simple terms, I can't even use a screen reader with KDE. KDE/Troltek know about this afaik but nothing can be done till other bits that will eventually e shared between gnome and KDE are done.
[05:11] <ScottK> I see.
[05:12] <bluesmoke> You would think someone would be paying for this work to happen if they really care about it
[05:13] <TheMuso> bluesmoke: What work?
[05:13] <bluesmoke> porting at-spi to dbus
[05:13] <bluesmoke> If Qt Software is stalled on that happening they could speed it up
[05:13] <TheMuso> bluesmoke: Its being done currently, but will take time.
[05:13] <TheMuso> bluesmoke: and accessibility is a minority thing, so there are not that many people who do care about it.
[05:14] <TheMuso> bluesmoke: And I am happy to wait. GNOME is serving me ok for now.
[06:13] <jharr> So is there a script somewhere that's responsible for building the ubuntu release ISOs?
[06:13] <dholbach> good morning
[06:14] <jharr> I've seen plenty of "customize ubuntu's live CD for your needs", but no "this is how ubuntu builds their release installers."
[06:14] <jharr> including the mini installers.
[06:15] <LaserJock> jharr: that's debian-cd and ubuntu-cdimage
[06:15] <jharr> LaserJock: thx.
[06:18] <jharr> is ubuntu-cdimage a package somewhere?
[06:18] <LaserJock> I don't think so
[06:18] <LaserJock> jharr: look at the Launchpad projects of the same name
[06:18] <LaserJock> and look at the bzr branches they have
[06:19] <jharr> LaserJock: cool, thx
[06:26]  * lamont tries to remember how to get X to spill a config
[07:42] <pitti> Good morning
[07:42] <LaserJock> uh oh, time for bed
[07:43] <LaserJock> hi pitti
[08:15] <tkamppeter> pitti, I got an answer on bug 318818, telling that an SRU consisting of a replacement of the released version by a newer upstream version needs TB approval and on the Wiki page https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions is written that the package build needs integrated regression tests (like CUPS has).
[08:15] <pitti> tkamppeter: I just replied to that
[08:31] <tkamppeter> pitt, thanks, I also replied to your comment now.
[08:44] <emgent> pitti: around ?
[08:44] <pitti> emgent: hi
[08:45] <emgent> hello pitti
[09:12]  * pitti watches the jaunty retracers behave well -- finally
[09:13]  * seb128 hugs pitti
[09:13] <seb128> pitti: how did you fix the apt error thing?
[09:14] <pitti> seb128: it was a bug in my "update apt cache for every retrace" commit
[09:14] <pitti> seb128: after apt.Cache.update() you must call apt.Cache.open()
[09:14]  * pitti hugs mvo
[09:15] <pitti> seb128: since the archive doesn't change that much for intrepid, we only saw it for jaunty
[09:15] <seb128> ah ok
[09:18] <pitti> tkamppeter: btw, the idea of pet-bug is to be bugs which are very old already and you always wanted to work on, but didn't have time for in earlier releases (due to focus on feature development); they shouldn't be used for recent bugs
[09:19] <pitti> tkamppeter: btw, is the cups SRU in the queue still valid, given that you recently proposed another pdftops fix in the bug?
[09:32] <amitk> Can somebody accept the arm binaries from the last kernel build: https://edge.launchpad.net/ubuntu/+source/linux/2.6.28-4.11/+build/840124
[09:34] <amitk> pitti: ^
[09:37] <ferrariii> hey i have tried to create a new workspace using the existing window manager on the host.. but i'm unable to do it .. .somebody please help me
[09:45] <ferrariii> hey i have tried to create a new workspace using the existing window manager on the host.. but i'm unable to do it .. .somebody please help me
[09:45] <pochu> ferrariii: this is not the right chanel for such questions, please ask in #ubuntu
[10:26] <pitti> amitk: I'm not sure to which components I should put them; had there ever been any kernel armel debs in jaunty?
[10:30] <amitk> pitti: not yet
[10:31] <amitk> cjwatson requested it
[10:31] <pitti> amitk: ok, I'll put them all into main then, and see what falls out later
[10:31] <amitk> pitti: thanks
[10:32] <amitk> pitti: I misread that. There were no udebs before
[10:33] <amitk> pitti: the debs existed as far back as -2.2 https://edge.launchpad.net/ubuntu/+source/linux/2.6.28-2.2/+build/802941
[10:33] <pitti> amitk: hm, I don't seem them on http://archive.ubuntu.com/ubuntu/pool/main/l/linux/
[10:34] <pitti> oh, ports
[10:34] <lool> zul: Hey, I think you uploaded the latest squid merge?  squid is uninstallable (and unupgradable) on all arches because squid-common was never rebuilt as the i386 build failed; did you have a look into this?
[10:35] <lool> directhex: Not sure whether you saw my ping yesterday: I heard you're working on the C# transition which affects f-spot, beagle, tomboy in the default install; it's been some days that these prevent upgrades; is there a bug for whatever blocks progress right now?
[10:36] <pitti> amitk: done
[10:37] <directhex> lool, i don't know if there's an open bug for it. AFAIK the problem(s?) are related to the gnome# library getting changes in debian experimental which require an abi bump & rebuild
[10:39] <seb128> ok, bug #197762 seems to be a frequent user complain, somebody wants to look at that for jaunty?
[10:39] <seb128> not sure if that's linux to blame or who should be assigned to the bug
[10:39] <seb128> bug #197762
[10:39] <directhex> lool, the one who knows most about it is slomo. if i get a chance today i'll try to investigate myself since he's rarely about
[10:40] <seb128> the bug mostly gets frustrated users comments right now
[10:40] <slomo> directhex: which bug?
[10:42] <directhex> slomo, something surrounding your gtk# or gnome# updates (which were merged around alpha2 time) causes issues. i think it might just need a resync, build-dep change, and rebuild. but i've not had time to investigate myself
[10:42] <directhex> i thyink sebner was investigating, but iirc he's off to do military service
[10:43] <slomo> the only problem i'm aware of (that shouldn't disappear by merging the latest versions of gnome#/gtk# and uploading gnome-desktop# from NEW) is, that many packages need to be transitioned for the gnome# API change
[10:43] <directhex> API, not just ABI? balls
[10:44] <lool> directhex: thanks
[10:44] <slomo> yes, there was quite some API cleanup... for example the panel applet stuff (which is not in gnome-platform but -desktop) was moved to gnome-desktop#
[10:44] <slomo> oh and the gnomeprint stuff too
[10:45] <directhex> blarg
[10:45] <directhex> lool, i don't know how much chance i'll get today though
[10:45] <lool> slomo: So the libs were pushed, but tomboy/f-spot/banshee aren't in a shape to use them?!
[10:46] <slomo> lool: no idea who had the great idea to sync/merge it to ubuntu :) tomboy only needs a build-dep change but iirc f-spot/banshee need some code/build system changes
[10:46] <lool> slomo: Lovely   :-/
[10:46]  * slangasek raises his hand
[10:47] <lool> slomo: Is upstream working on porting?
[10:48] <slangasek> getting rid of mono 1.0 is going to be a significant savings on our CDs; unfortunately I didn't learn until after merging gnome-sharp2 from experimental that the pieces weren't all there yet
[10:48] <slomo> lool: no idea about f-spot but for banshee i have this on my todo list ;)
[10:48] <directhex> to be fair to slangasek, he was only trying to help, and i don't think anyone realised what a bad idea using gnome# from experimental was (whilst we were busily recommending everything ELSE mono related from experimental was great)
[10:48] <slomo> i guess i should've been a bit more explicit in the changelog :)
[10:49] <directhex> realistic question: does this warrant an epoch?
[10:49]  * slangasek whimper
[10:50] <directhex> i don't know how much trouble the API change will cause
[10:50] <lool> I'd rather not epoch in Ubuntu and not in Debian
[10:50] <directhex> lool, i know, but slomo's in charge of gnome# in both
[10:52] <slomo> well, it should be fairly easy to port all packages... it just needs someone to do it ;)
[10:52] <lool> slomo: Actually banshee is installable
[10:52] <lool> So it's only tomboy and f-spot for me, and tomboy is said to be trivial
[10:54] <slomo> yes, tomboy is just a b-d change... i'm surprised that banshee works though. libgconf2.0-cil became libgconf2.24-cil
[10:54] <slomo> same for libgnome2.0-cil
[10:54] <tkamppeter> pitti, did you get my answers on your last messages here? Or did you reply something? I had a network interruption shorttly after that?
[10:54] <slomo> so i guess the old binary packages are still there or something
[10:54] <pitti> tkamppeter: I didn't get answers from you
[10:55] <tkamppeter> So I will repost them:
[10:55] <seb128> I would rather try to update f-spot if upstream didn't yet than use an epoch
[10:55] <tkamppeter> sorry, I thought these are the bugs I thought to be most important or put the most effort into.
[10:55] <lool> slomo: I don't know whether it works, it's just installable
[10:55] <tkamppeter> pitti, the fix in the pdftopdf filter which is the proposed SRU fixes a regression against Hardy and so makes the behavior of the filter workflow in the cases mentioned by the bug at least equal Hardy. The proposed fixes on pdftops and pstopdf in the last 5 or so postings are to really fix the problem of mixed-page-size documents and printing with the paper size given by the document.
[10:55] <slomo> lool: ok :)
[10:55] <slomo> well, i've to get some food now... bbl
[10:56] <pitti> tkamppeter: if there wasn't an explicit "LSB compat" fix, but LSB compat only broke due to the other regressions, that's fine
[10:56] <pitti> tkamppeter: okay, so the current upload in intrepid-proposed is not obsolete then?
[10:56] <tkamppeter> pitti. yes.
[11:23] <pitti> seb128: did you ever see a double-pkgstriptranslations build as in http://launchpadlibrarian.net/21351698/buildlog_ubuntu-jaunty-i386.glib2.0_2.19.5-0ubuntu1_FULLYBUILT.txt.gz ?
[11:24] <seb128> pitti: no, just the one which got mentionned on #soyuz yesterday
[11:24] <pitti> I tried to replicate it locally, without success, and had a long hard stare at the code
[11:24] <pitti> I have NFC where it would fork
[11:24] <seb128> pitti: how would you notice it out of a publisher crash?
[11:25] <pitti> hm, good question
[11:25] <seb128> I don't look at build logs so closely when the build success usually
[11:26] <slomo> lool, directhex: for porting just keep in mind that platform stuff is now in gnome-desktop# (i.e. panel applet, gnomeprint), that all pkg-config files have a different version number now and that every removed method will have a better alternative (iirc some deprecated/obsoleted methods were removed)
[11:26] <pitti> seb128: well, if that was the reason for the publisher crash, then I guess it didn't happen before
[11:28]  * pitti spots "InterpreterPath: /target/usr/bin/perl" in a crash report and sighs -- aufs FTW
[11:33] <james_w> pitti: there's someone in #ubuntu-bugs with a report of a regression in Intrepid. metacity is now segfaulting on login.
[11:33] <james_w> pitti: so far it is hinting towards libc6 in -proposed or cups in -security
[11:33] <pitti> james_w: uh, we didn't update that for a while
[11:34] <james_w> pitti: I'm asking them to narrow it down as we speak
[11:34] <pitti> james_w: libc6 was updated 11 days ago for some fortify regression fixes
[11:34] <pitti> james_w: so he runs -proposed?
[11:34] <james_w> http://pastebin.com/m711f0ba5 <- stacktrace  http://pastebin.com/d7369120b <- which-pkg-broke
[11:34] <james_w> yeah, -proposed enabled
[11:34] <james_w> and those two packages updated today as you can see
[11:36] <pitti> so downgrading libc6 or libcups2 should telll
[11:37] <james_w> they're currently downgrading libc6
[11:37] <james_w> perhaps I should have started with cups actually
[11:39] <pitti> james_w: the cups security update only affected the scheduler, not the library
[11:39] <james_w> pitti: interesting, thanks
[11:39] <james_w> I'll let you know how things go, but I wanted to mention it early
[11:40] <pitti> james_w: thanks a heap!
[11:44] <pitti> james_w: where is which-pkg-broke? apt-cache search doesn't catch that
[11:44] <james_w> pitti: debian-goodies
[11:44] <pitti> awesome
[11:44] <james_w> really useful tool
[11:46] <james_w> pitti: will a downgrade of libc6 require a restart for metacity to start using the new one?
[11:47] <pitti> james_w: yes, but I thought it previously crashed on startup?
[11:47] <pitti> all running programs need to be restarted for using the new libc6
[11:47] <james_w> k
[11:47] <james_w> they have rebooted since the upgrade
[11:47] <james_w> but not since the downgrade
[11:47] <james_w> and it crashes when metacity starts, they are using an alternative WM at the moment
[11:47] <pitti> then it should work immediately
[11:48] <pitti> james_w: of course, theoretically, it could also be libcups2 now misbuilding due to new glibc, or something similarly hairy
[11:48] <james_w> urgh
[11:48] <pitti> so downgrading that too is still worthwhile testing
[11:49] <james_w> yup
[11:50] <james_w> the cause of the bug seems to be an empty gconf setting though, but that is a bit odd
[12:32] <pitti> seb128: FYI, all bugs are retraced now, and retracer is fully on auto
[12:41] <seb128> pitti: excellent!
[13:18] <apw> superm1, hey you about?
[13:20] <james_w> pitti: panic off it seems. Corrupted gconf defaults were the cause. Why that happened is not clear, but I can't see a link to the updates.
[13:21] <directhex> shameless plug: http://ubuntuforums.org/showthread.php?p=6584115
[13:26] <tseliot1> directhex: no repository for jaunty?
[13:27] <directhex> tseliot1, no. do you want one? it's the same source package for any dist with cairo >= 1.8
[13:27] <tseliot1> directhex: sorry, I had missed the line about Jaunty in your post
[13:28] <directhex> tseliot1, it's not in jaunty yet due to NEW slowness (when it's in exp i'll requestsync)
[13:28] <directhex> tseliot1, but if you like, i can just quickly upload a jaunty version to my ppa
[13:28] <tseliot1> directhex: please do it :-)
[13:29] <directhex> uploaded. waiting for build.
[13:29] <tseliot1> directhex: thanks a lot
[13:31] <directhex> build started
[13:33] <tseliot1> great
[13:35] <seb128> james_w: we get some bugs every now and then where the gconf settings are not correctly set for some softwares, there is a bug open about this bug gconf doesn't log enough to give a real clue about when and how that's happening, and usually doing a new schemas registration works correctly
[13:35] <directhex> it's a 9 minute build.
[13:35] <james_w> seb128: sounds about right
[13:43] <liw> if I suspect a license problem with a package in Ubuntu, what should I do?
[13:45] <liw> that is, is reporting it as a public bug the right way to do it?
[13:46] <directhex> tseliot1, build, pending the usual LP delays creating Packages.gz
[13:46] <directhex> s/build/built/
[13:47] <tseliot1> directhex: thanks again
[13:47] <directhex> tseliot1, no problem - i'm pleased as anything to avoid a disappointing miss for moon as happened with the olympics
[13:52] <kagou> Hi
[13:52] <kagou> Hi, I'm testing beta of bibble5. Bibble5 is not compiled for 64bits, so I'v installed ia32 and bibble5 is ok. In the last beta libuuid1 is needed, but libuuid1 installed is for x86-64 architecture.
[13:52] <kagou> I can not find an elegant way to install the 32bit version of this lib
[13:53] <kagou> I'v manually downloaded and manually extracted lib in /lib32 but it's dirty
[13:53] <kagou> is there a way to simplify this ?
[13:53] <maxb> No, there is no elegant way to install 32bit libs if they are not specifically packaged
[13:54] <kagou> maxb, is there a possibility to use a 64lib in a 32bit emulation ?
[13:54] <maxb> no
[13:54] <kagou> wow that's problematic
[13:54] <Keybuk> dholbach: does your nag script take into account bugs that were tagged for sponsoring, but for which the tag was removed and the sponsor subscribed themselves to chase for more information? :p
[13:54] <kagou> maxb, thanks
[13:59] <dholbach> Keybuk: it counts uploads and bug traffic on the sponsoring mailing lists
[14:00] <dholbach> Keybuk: which tag are you using there?
[14:47] <PeakerWork> I remember "deb-make" could make a debian package out of a normal source. What replaced it?
[14:47] <PeakerWork> I want to build a package for the newest git sources
[14:48] <directhex> there's no way to create a package without doing some actual packaging work which doesn't suck hard
[14:48] <directhex> you MIGHT be thinking of dh_make (which creates a skeleton packaging setup)
[14:48] <directhex> you might be thinking of checkinstall (which takes some source & jumps all over your /usr
[14:49] <PeakerWork> dh_make yeah
[14:53] <jdstrand> pitti: hi! regarding my ufw SRU. A bug just came in today that I would like to fix in that SRU. would you mind if I revved the version with the fix and updated the bug, or would it be better to hold off and do another SRU later?
[14:53] <pitti> jdstrand: is it a bug in the changes you made to that SRU, or an independent one?
[14:54] <pitti> jdstrand: usually it's better to shove through one SRU completely, then start with the next round
[14:54] <pitti> and in the mean time, stash changes into bzr
[14:54] <jdstrand> pitti: it is a completely new, unique bug
[14:54] <jdstrand> pitti: independent of that SRU
[14:55] <pitti> jdstrand: second, the new bug should match the SRU criteria (some in the previous one really were borderline, like the removal of rc0.d symlink)
[14:55] <jdstrand> pitti: oh, I thought we discussed that one on IRC...
[14:56] <jdstrand> pitti: but I don't think you'll have a problem with me fixing this new one
[14:56] <jdstrand> :)
[14:56] <pitti> jdstrand: yes, and I approved it :) but as I said, I think it's borderline
[14:56] <jdstrand> bug #319226
[14:57] <jdstrand> pitti: cool. btw, on a totally unrelated note-- while I always had procmail recipes for my ubuntu email, your talk in UDS on how you have your four classes of email *totally* helped me out
[14:57] <pitti> jdstrand: depends on how it fails, I guess
[14:57] <pitti> jdstrand: glad to hear it :)
[14:58] <jdstrand> pitti: I'm actually able to see things as they come in and not be completely buried
[14:58] <jdstrand> pitti: thanks! :)
[14:58] <pitti> jdstrand: my feeling as well, it allows me to keep up with the important bits without getting swamped
[14:59] <jdstrand> pitti: re bug> it exits with error about finding a hidden file in the ufw directory. It is a superfluous check, cause I don't read in any hidden files anyway...
[15:00] <jdstrand> pitti: but I'll just do another SRU, as you suggested
[15:00] <pitti> jdstrand: it doesn't sound very urgent, so I'd recommend waiting until this one is in -updates
[15:00] <jdstrand> pitti: np. thanks for your feedback :)
[15:00] <pitti> jdstrand: (people will either have noticed by now and found a workaround, or are using a completely different solution by now)
[15:02]  * jdstrand nods
[15:16] <directhex> tseliot1, does that package work for you? i posted a link to a SL game which should be an adequate test
[15:17] <tseliot1> directhex: it didn't but I'm running firefox 3.1. I had to install the firefox extension manually
[15:18] <directhex> tseliot1, it ought to work on 3.1, the deps were fiddled especially
[15:18] <tseliot1> directhex: I doubt it's specific to your package though. The same happened to me with some other plugins before
[15:19] <directhex> tseliot1, is this ff3.1 from the mozillateam ppa?
[15:19] <tseliot1> directhex: no, I extracted the tarball from mozilla's website
[15:19] <directhex> tseliot1, aha. do you want to get the package working, or do you prefer to use the .xpi?
[15:20] <ogra> oooh, cjwatson is back :)
[15:20] <directhex> tseliot1, symlink /usr/lib/moon/plugin/libmoonloader.so in your tarball firerfox's plugins folder. it doesn't check /usr/lib/xulrunner-addons, which is an ubuntuism
[15:20]  * ogra gently points cjwatson to the ubuntu-devel ML discussion about debootstrap
[15:21] <tseliot1> directhex: ah, ok thanks
[15:21] <directhex> tseliot1, applies generally for plugin packages
[15:21] <tseliot1> yes, I picked that up
[15:24] <cjwatson> ogra: ok
[15:24] <ogra> ha! i knew i'd get Keybuk intrested in the thread if i mention upstart somewhere ... that magically summons him *g*
[15:26] <Keybuk> ogra: err, you mentioned Upstart?
[15:26] <ogra> indeed i did
[15:26] <Keybuk> I didn't notice that
[15:26] <Keybuk> I jumped into the thread because cjwatson and I were just talking about debootstrap and making devices the other day
[15:26] <ogra> ah
[15:27] <cjwatson> ogra: actually, the only thing I wanted to say has already been said
[15:27] <ogra> Keybuk, init does if it cant write to /dev/console, so indeed i mentioned upstart :)
[15:27] <cjwatson> ogra: i.e. it's already in backports (and pitti also said that SRUs for stable releases would be fine, which I agree with)
[15:28] <ogra> cjwatson, backports ?
[15:28] <cjwatson> yes, backports
[15:28] <ogra> i'm talking about jaunty there
[15:28] <Keybuk> ogra: init does what?
[15:28]  * ogra should probabaly have mentioned that
[15:28] <pitti> well, I said that *backports* are fine, and that I'd rather not stuff it into SRUs
[15:28] <cjwatson> ogra: are we looking at different threads? I'm looking at Subject: piuparts, debootstrap and newer releases
[15:28] <ogra> cjwatson, "missing /dev/console in debootstrap --foreign, a bug or not ?"
[15:29] <cjwatson> pitti: err, right, sorry, I oversimplified. (You did say that it would be bearable but you'd rather not.)
[15:29] <cjwatson> ogra: oh, I haven't pulled down all my mail yet. I'll get to it
[15:29] <Keybuk> ogra: looking at debootstrap's code, I can't see why /dev/console would be missing
[15:29] <pitti> well, either way; if we need them for something, let's do them
[15:29] <cjwatson> pitti: as people said, they're already in backports
[15:29] <ogra> Keybuk, "attempting to kill init" involves upstart (in some remote way :) )
[15:29] <Keybuk> oh, wait, yes I can
[15:29] <Keybuk> ogra: sure, you can't start any init if you don't have at least /dev/console or /dev/null
[15:29] <cjwatson> I've been sticking debootstrap into backports myself for years anyway, since I know the backport is trivial :)
[15:29] <Keybuk> that's not Upstart specific
[15:30] <ogra> Keybuk, thats what my mail said :)
[15:30] <Keybuk> cjwatson: so it turns out that "console" is not made by MAKEDEV std
[15:30] <cjwatson> Keybuk: so add consoleonly to that?
[15:30] <ogra> Keybuk, it also said that you could (indeed thats very ugly) make init call mknod first :)
[15:30] <Keybuk> consoleonly makes other things too
[15:31] <Keybuk> ogra: no I can't, the filesystem is read-only
[15:31] <cjwatson> consoleonly makes one other device, namely tty0
[15:31] <Riddell> pitti: you uploaded calibre?  it includes code under the four clause BSD which would be incompatible with the GPLed code
[15:31] <ogra> oh, right
[15:31] <Keybuk> cjwatson: oh, sorry, was reading console)
[15:31] <cjwatson> which doesn't seem like too much of an imposition
[15:31] <Keybuk> . o O { man, makedev doesn't do anywhere near anything similar to udev }
[15:31] <pitti> Riddell: oh argh, forgot about that
[15:32] <cjwatson> Keybuk: btw, mind if I upload udev? I fixed its udeb earlier today
[15:32] <Keybuk> cjwatson: how did you fix it?
[15:32] <cjwatson> added lib/udev/devices/{net,pts,shm} to udev-udeb.dirs
[15:32] <cjwatson> udev.installer-startup got kind of upset when cp /lib/udev/devices/* failed
[15:32] <pitti> Riddell: it's used in a plugin in calibre-bin (msdes.so)
[15:33] <Keybuk> heh, sure
[15:33] <pitti> Riddell: what was that problem again, the advertising clause/
[15:33] <pitti> ?
[15:34] <Riddell> pitti: yes (well potential problem still looking at it)
[15:34] <Keybuk> cjwatson: I haven't thought about the groups issue yet
[15:34] <cjwatson> Keybuk: that's OK, it's cosmetic rather than important
[15:35] <Keybuk> we may end up just growing udevd --no-groups or something
[15:35] <cjwatson> aye, that's the kind of thing I was thinking about
[15:36] <cjwatson> I couldn't imagine you wanting to tweezer apart all the rules again just for the udeb
[15:37] <wasabi> Hmm. All this talk about Wine is interesting. I wonder if we're every going to get it to integrate so it acts like eral windows with regards to having per-machine stuff.
[15:38] <cjwatson> Keybuk: so what do I need to do with bzr-builddeb to make this build properly?
[15:38] <Keybuk> cjwatson: you can't ;)
[15:38] <Riddell> pitti: so it's a GPL 3 python app loading and using an incompatible licence plugin
[15:38] <cjwatson> I don't think I remember the conclusion of your discussion with James
[15:38] <cjwatson> Keybuk: ah. what's the magic dpkg-buildpackage argument then? :-)
[15:39] <Keybuk> cjwatson: bzr clean-tree && dpkg-buildpackage -S -i(.bzr|.git-ignore|test)
[15:39] <Keybuk> iirc
[15:39] <pitti> Riddell: merely shipping the source is okay, right? so if I just disabled building and shipping the plugin it should be okay, until we sort this out with upstream?
[15:39] <Riddell> pitti: yes that's fine
[15:39] <Keybuk> err
[15:39] <Keybuk> cjwatson: bzr clean-tree && dpkg-buildpackage -S -i(.bzr|.gitignore|test)
[15:40] <Riddell> pitti: I'll reject for now then
[15:40] <pitti> Riddell: okay
[15:40] <cjwatson> Keybuk: yeah, that does the right thing, thanks
[15:41] <Dreig_> http://www.pennergame.de/change_please/6086543/
[15:43] <dholbach> Ubuntu Developer Week - Day 2 just about to start in 17m in #ubuntu-classroom :)
[15:43]  * pitti is still creating his talk...
[15:43] <Jarlen> yay :)
[15:44] <Jarlen> it was a really nice start yesterday
[15:44] <dholbach> pitti: you luckily still have a bit of time left :)
[15:44] <dholbach> Jarlen: yeah, it was fantastic :)
[15:45] <Jarlen> well, depends on how you define fantastic
[15:45] <dholbach> in my view it was FANTASTIC :)
[15:45] <Jarlen> if you rule out that I didn't make 50% of my homework because I was reading Ubuntu developer stuff, then yah, it was fantastic :P
[15:45]  * dholbach hugs Jarlen
[15:46] <Jarlen> from an ubuntu point of view, I really enjoyed it!
[15:47] <Jarlen> is there ever any events like this from a community point of view, instead of the developer POV?
[15:47] <dholbach> Jarlen: there's an Ubuntu Open Week two times a year too
[15:47] <dholbach> other sessions are less regular
[15:48] <Riddell> pitti: do you know what's to be done with the language packs waiting in hardy-proposed New?
[15:48] <Jarlen> dholbach: ah, yeah, the open week looks a bit more diverse
[15:48] <pitti> Riddell: they should just be rejected IMHO, we haven't introduced new langauges into stables so far
[15:48] <dholbach> Jarlen: less focussed on development
[15:49] <Jarlen> we're working on a community track for the danish 9.04 release party, so some inspiration could be great :)
[15:49] <Riddell> pitti: ok, seems a bit harsh on the people doing the translations needlessly though
[15:49] <dholbach> Jarlen: best to ask your users what they'd like to see :)
[15:49] <Jarlen> and a global IRC session/brainstorm/week to get inspired would be a great start :)
[15:52] <cjwatson> pitti: we haven't? I'm sure I've accepted new language packs into stables lots of times
[15:52] <cjwatson> inc. when you were driving langpack-o-matic :-)
[15:53] <pitti> cjwatson: yeah, unfortunately it still spits out new languages, since we do not have a per-release list of supported locales
[15:53] <cjwatson> I don't see it as a big deal to accept them
[15:53] <pitti> i. e. new locales which got introduced into e. g. intrepid or jaunty aren't present yet in dapper and hardy
[15:53] <pitti> no, it's not a big deal, I just didn't do it so far
[16:08] <Baby> pitti: ping!
[16:09] <pitti> Baby: pong
[16:10] <Baby> pitti: which file was BDS4? there was one in old versions but upstream replaced it
[16:10] <pitti> Baby: the msdes stuff?
[16:11] <Baby> yup
[16:11] <pitti> Baby: oh, indeed that's not BSD any more, but public domain and GPL 2+
[16:11] <pitti> so we just need to fix the copyright file
[16:11] <Baby> in the version I uploaded to Debian it is not BDS4
[16:11] <Baby> yup
[16:11] <pitti> Riddell: ^ will do that, it was just obsolete debian/copyright
[16:12] <Baby> I had 2 or 3 mails with upstream some time ago to fix that :)
[16:12] <Riddell> nice
[16:12] <Baby> :)
[16:13] <pitti> right, I'll upload the current bzr head to Ubuntu then
[16:13] <Baby> we might think about upgrading it to latest version
[16:13] <Baby> upstream releases once or twice a day XD
[16:14] <Baby> usually with just one or 2 lines of change between versions
[16:14] <pitti> Baby: that, too
[16:14] <Baby> XD
[16:14] <pitti> Riddell: anything else which was wrong with it?
[16:14] <Riddell> pitti: nope
[16:16] <Baby> the only issues I found were that BSD4 thing and the fonts, and they were both fixed :)
[16:18] <nijaba> dholbach: did soren reply to you regarding tomorrow presentation?
[16:18] <dholbach> nijaba: no, he didn't
[16:18] <nijaba> dholbach: I guess he is really sick
[16:29] <jsmidt> Which command will merge Ubuntu and Debian changelogs?
[17:13] <tseliot1> directhex: now it tells me that moonlight was compiled with 1.0 support only while 2.0 is required
[17:33] <tkamppeter> pitti, did you have another look at the foomatic-filters SRU? bug 318816, bug 318818, bug 299918, bug 303691
[17:33] <pitti> tkamppeter: I thought we sorted that out this morning? I'm ok with it
[17:34] <tkamppeter> pitti, can you then approve the foomatic-filters package to enter -proposed? And can you also let the cups package enter -proposed? Thanks.
[17:35] <pitti> tkamppeter: yep, will do next time I'll process SRU
[17:38] <tkamppeter> pitti, which day/time is SRU for you?
[17:39] <pitti> tkamppeter: every other day roughly
[17:53] <Golgata> hope someone can help me. i want to create a container usable with virtualbox which i can later burn to a dvd... sb got an idea?
[17:54] <tuxcrafter> hi all , i saw the discussion about the debootstrap on the mailinglist
[17:54] <tuxcrafter> i would like to ask some questions about this
[17:55] <tuxcrafter> i am doing some testing on emdebian and i got the following error while debootstrapping
[17:55] <tuxcrafter> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512067
[17:55] <Golgata> maybe customizing the ubuntu-livecd is easier?
[17:56] <tuxcrafter> does somebody know where this bug comes from it is very similair as the issue descussed on the ubuntu-devel mailinglsit
[17:57] <Keybuk> tuxcrafter: sounds like you're using a sysvinit tool
[17:58] <tuxcrafter> Keybuk: i think some sub script needs some device node...
[17:58] <tuxcrafter> because sysvinit should know not to start services when in debootstrap
[17:58] <Keybuk> Ubuntu does not use sysvinit
[17:59] <tuxcrafter> true .. :-p upstart
[17:59] <kirkland> pitti: hey, can you push ecrypftfs-utils 53-1ubuntu13 from proposed -> updates?  it's been in proposed since 2008-11-05
[17:59] <Keybuk> there is no /dev/initctl in Ubuntu
[17:59] <cjwatson> it sounds entirely unrelated to the issue recently discussed on ubuntu-devel, to me
[18:00] <tuxcrafter> cjwatson: it could be i am still trying to get more info on the issue
[18:05] <cjwatson> tuxcrafter: (I fixed the issue recently discussed on ubuntu-devel, and am fairly confident ...)
[18:09] <tuxcrafter> cjwatson: how did you debug your issue?
[18:12] <cjwatson> tuxcrafter: I already know debootstrap very well, so that probably isn't much use to you; besides, when I turned up today people had already more or less figured it out
[18:13] <cjwatson> tuxcrafter: FWIW debootstrap's Makefile (in the source package) calls MAKEDEV with some arguments, and you can look up what those arguments do in /sbin/MAKEDEV
[18:14] <cjwatson> tuxcrafter: somebody should extract /debootstrap/debootstrap.log from the failed chroot and attach it to that bug report; it is likely to offer more detail
[18:19] <tuxcrafter> cjwatson: i will start searching for the debootsrap log, did you used some book/website to get all your knolage of debootstrap or did you investigated the code?
[18:20] <ogra> cjwatson, thans for the quick fix ! :)
[18:20] <ogra> *thanks even
[18:22] <fabbione> Keybuk: what's the rationale for forcing udev rule files from /etc/ to /lib.. ? I can see in other distro that it's possible to use both directories...
[18:23] <fabbione> Keybuk: specifically they use /lib for rules that should not be modified by the users (like all those *persistent* stuff) and left the others in /etc untouched
[18:24] <cjwatson> tuxcrafter: I read and worked on the code
[18:24] <Keybuk> fabbione: udev rules aren't configuration files in the normal sense, but a turing complete programming language
[18:24] <Keybuk> those shipped by a distribution that provide the *default* behaviour should be considered acting and behaving as built-ins
[18:24] <Keybuk> so are shipped in /lib
[18:25] <Keybuk> (a future udev could compile them into the udevd binary, for example)
[18:25] <Keybuk> udevd reads /etc/udev/rules.d afterwards, so any user rules can override anything made by default
[18:25] <Keybuk> separating the files means that a user's own rules become individual in their own right
[18:25] <Keybuk> and aren't confused by upgrades, etc.
[18:26] <Keybuk> this isn't an Ubuntu-specific change
[18:26] <Keybuk> in fact, in jaunty, the primary change has been to drop the old Ubuntu rules files and instead use standard upstream rules files
[18:26] <fabbione> Keybuk: hmm ok.. yeah i know it's not Ubuntu-Specific..
[18:26] <Keybuk> these are shared between Ubuntu, Fedora (so RHEL too), Gentoo and SuSE
[18:26] <fabbione> that's why i know other distros allow both
[18:26] <fabbione> yeps :)
[18:27] <Keybuk> we just happened to be a bit quicker at moving everything from /etc to /lib because our upload privilege system allows one person to make the changes
[18:27] <Keybuk> the plan is that all distributions would move to their packages shipping rules in /lib over time
[18:27] <fabbione> actually you are not that quicker at all
[18:27] <fabbione>  /lib was used in F10 and before alread
[18:27] <Keybuk> right. but F10 only uses /lib for the rules shipped by udev itself, not by third party packages, right?
[18:28] <fabbione> for what i can see...
[18:28] <Keybuk> my understanding was that the latter transition was expected to take longer
[18:28] <Keybuk> (from harald)
[18:28] <fabbione> hmmm
[18:28] <Keybuk> upstream software should also now feel confident about just installing rules into /lib/udev/rules.d by default
[18:28] <fabbione> thinking out loud...
[18:28] <Keybuk> and expect that to work on most of the major distributions
[18:29] <fabbione> is it possible to disable certain *persistent* rule in a configurable fashion?
[18:29] <Keybuk> yes
[18:29] <fabbione> the reason why i jumped in to ask is because i can fix upstream as well (for redhat-cluster at least) to match new distro fashions ;)
[18:29] <fabbione> so we don't have to carry around deltas for nothing
[18:30] <Keybuk> if you install to /lib/udev/rules.d, you're obviously free to GOTO over a rule supplied by upstream udev
[18:30] <Keybuk> (assuming that's what you mean?)
[18:30] <fabbione> example: persistent-net-foo.rule in /lib...
[18:31] <fabbione> the one that generates ethX <-> Mac association
[18:31] <Keybuk> the 70-persistent-{cd,net}.rules files are in /etc because they're configuration
[18:31] <fabbione> i don't want it enabled... can I disable it?
[18:31] <Keybuk> sure
[18:31] <Keybuk> echo '#disabled' > /etc/udev/rules.d/75-persistent-net-generator.rules
[18:31] <fabbione> how will that work in the new system?
[18:31] <fabbione> ok
[18:31] <Keybuk> files in /etc trump default rules
[18:31] <fabbione> so if the file is /lib../75-persistent-net-generator.rules
[18:32] <fabbione> and there is an equivalent in /etc...
[18:32] <fabbione> the one in etc > lib ?
[18:32] <fabbione> right?
[18:32] <Keybuk> then the file in /etc is used insteead
[18:32] <fabbione> ok perfect
[18:32] <fabbione> sounds good
[18:32] <Keybuk> that's the correct way to deal with "I just don't want this functionality" kind of behaviour
[18:32] <Keybuk> for example, also if you wanted to specifically not run programs, etc.
[18:32] <Keybuk> otherwise you'd normally just create your own files, /etc/udev/rules.d/50-fabbione.rules etc.
[18:33] <fabbione> gotcha
[18:33] <fabbione> thanks
[18:33] <Keybuk> you can also disable the generator rules by something like:
[18:33] <cjwatson> fabbione: FWIW, the README files in /{etc,lib}/udev/rules.d/ document this
[18:33] <Keybuk>   /etc/udev/rules.d/10-fabbione.rules:
[18:33] <fabbione> it's mainly because i have some fancy hw where some of those things fail
[18:33] <Keybuk>     SUBSYSTEM=="net", NAME="%k"
[18:33] <Keybuk> fabbione: we'd like to know about that fancy hardware; your personal customisation is likely something we should ship in udev by default!
[18:33] <fabbione> cjwatson: ok thanks..
[18:34] <fabbione> Keybuk: no you don't :) I am sure as soon as I mention that architecture that starts with S and ends with 64 you run away screaming :P
[18:34] <Keybuk> fabbione: if it's an architecture supported by the linux kernel, it should be supported by upstream udev
[18:35] <fabbione> Keybuk: for example on sparc, it's very common that all onboard NIC share the same Mac address
[18:35] <Keybuk> iirc, on sparc, the onboard nics can be identified by something else though, right?
[18:35] <fabbione> Keybuk: on hardy it triggers a rename race in udev because of the different net-generator/net-keep-the-same-eth etc. scripts
[18:35] <Keybuk> yeah, that's something we should certainly support upstream
[18:36] <fabbione> Keybuk: it depends from the hw.  not all of them do and it's not that easy as it involves a much more complex operation in poking into OBP
[18:36] <fabbione> Keybuk: where often OBP mapping != kernel mapping...
[18:37] <fabbione> Keybuk: anyway i appreciate all your explanation. I'll fix my little upstream corner once i am back from sick leave
[18:37] <Keybuk> np
[18:37] <Keybuk> most of us (including kay and harald) hang out on #udev as well
[18:38] <fabbione> oh it's alright.. i really don't have time to hack that too
[18:38] <fabbione> you might want to know that udev works just fine on m68k...
[18:38] <fabbione> even after a potato -> sid dist-upgrade ;)
[18:46] <liw> what's the process of getting an application included in the default Ubuntu desktop install? who decides this?
[18:46] <tjaalton> Keybuk: hey, I've got problems with jaunty and root on SAN (multipath). init gives up waiting for root, so I'm dropped in busybox, but running kpartx manually and exiting the shell makes the boot resume
[18:47] <Keybuk> tjaalton: I don't know much about multipath I'm afraid
[18:47] <Keybuk> is multipath-tools and its udev rules installed into the initramfs?
[18:47] <tjaalton> yes
[18:47] <tjaalton> hence kpartx working
[18:47] <tjaalton> but what I'm thinking is that maybe it gives up too early
[18:47] <maxb> liw: Is it packaged? Is it in main?
[18:48] <tjaalton> it takes some time to probe the devices
[18:48] <liw> maxb, is packaged, is in main (system-cleaner-gtk is the package)
[18:48] <Keybuk> is there a /lib/udev/rules.d/*-multipath.rules ?
[18:48] <tjaalton> Keybuk: yes
[18:48] <Keybuk> is there a /lib/udev/rules.d/*-kpartx.rules ?
[18:48] <tjaalton> yes
[18:48] <Keybuk> tjaalton: what number has the kpartx.rules ?
[18:49] <tjaalton> Keybuk: 95-
[18:49] <cjwatson> liw: any core developer may edit the seeds
[18:49] <Keybuk> tjaalton: no idea then, sounds like it should all work to me
[18:49] <cjwatson> liw: if it's likely to be controversial, a discussion on ubuntu-devel@ or ubuntu-desktop@ would be polite
[18:49] <cjwatson> liw: there's no more heavyweight process than that
[18:49] <Keybuk> tjaalton: that rules file runs kpartx for you when devices are added
[18:50] <liw> cjwatson, ack, I*ll e-mail ubuntu-desktop (I assume that's the more appropriate list)
[18:50] <tjaalton> Keybuk: but what if I'm dropped to busybox before it's run?
[18:50]  * ScottK alters the Kubuntu seeds every time Riddell takes a vacation.
[18:50] <tjaalton> is it possible?
[18:50] <Keybuk> tjaalton: there's a three minute timeout
[18:50] <Keybuk> if it takes more than three minutes to setup, sure, you'll be dropped to busybox first
[18:51] <tjaalton> Keybuk: oh, it's certainly shorter.. maybe 10sec
[18:51] <Keybuk> actually it might only be 30s now
[18:52] <tjaalton> I need to measure it..
[18:52] <Keybuk> shorter than that implies it failed to mount perhaps?
[18:52] <Keybuk> did it say "Gave up waiting" ?
[18:52] <tjaalton> the error message says that it didn't find root, and the devices are not set up either
[18:52] <Keybuk> or "Could not mount"
[18:52] <tjaalton> the former
[18:53] <Keybuk> implies that the device setup hasn't worked then
[18:53] <tjaalton> is there a way to add some debug output?
[18:54] <Keybuk> nothing automatic
[18:55] <Keybuk> boot with break=premount
[18:55] <Keybuk> rm scripts/init-premount/udev
[18:55] <Keybuk> /sbin/udevd --debug > /dev/udev.log 2>&1 &
[18:55] <Keybuk> (wait a second or two)
[18:55] <Keybuk> /sbin/udevadm trigger
[18:55] <Keybuk> then ^D to continue the boot as before
[18:55] <tjaalton> great, thanks.. I'll try that first thing tomorrow
[18:56] <Keybuk> please be sure to mark the udev.log *before* you run kpartx by hand
[18:56] <Keybuk> tbh, I would actually at that point kill the running udevd
[18:56] <Keybuk> then start another one up with a different log file
[18:56] <Keybuk> (so we can see what happens when you run kpartx)
[18:56] <tjaalton> ok, I'll play with it
[19:07] <ScottK> cjwatson: Congratualtions on tech board.
[19:07] <cjwatson> thanks!
[19:07] <cjwatson> though somebody still needs to actually add me to the team ;-)
[19:10] <jpds> cjwatson: Congrats!
[19:10] <james_w> congratulations cjwatson
[19:11]  * robbiew gives a "whoohoo!" for cjwatson
[19:11] <liw> cjwatson, onneksi olkoon
[19:12] <robbiew> ??????
[19:12] <robbiew> :P
[19:12] <liw> "congratulations" in Finnish. no point in wasting an opportunity to be weird.
[19:13] <lool> cjwatson: Thanks for the debootstrap fix
[19:14] <lool> cjwatson: Should I forward to Debian?
[19:14] <cjwatson> lool: I already committed it upstream (i.e. Debian)
[19:14] <cjwatson> so thanks but no need
[19:14] <cjwatson> can't upload it because the installer is frozen, but it's in svn
[19:17] <pitti> cjwatson: congratulations, and many thanks for your always insightful and correct advice
[19:20] <lfaraone> Hi, would problems with the livecd "shut down" option not actually powering off after halt be a bug in casper, or what?
[19:21] <ogra> cjwatson, oh, you made it ! congrats :)
[19:25] <cjwatson> lfaraone: depends; if it's due to filesystems not being unmounted or something similar, then yes - but, if possible, try to find out if an installed system doesn't manage to power off either
[19:25] <cjwatson> lfaraone: if the latter is the case, then it's likely that the kernel needs to add an ACPI quirk for your system, and the way to get that done is to file a bug on the kernel and attach the output of dmidecode
[19:25] <lfaraone> cjwatson: well, it _does_ power off in intrepid, I don't have an install d jaunty system.
[19:26] <lfaraone> *on this system
[19:26] <cjwatson> lfaraone: there are various reboot= parameters one can give to the kernel to tweak this
[19:26] <cjwatson> otherwise, debugging it is probably a somewhat tedious matter of adding set -x to bits of the init system called on shutdown
[19:26] <lfaraone> cjwatson: it prints out its final "system halted" screen but doesn't die.
[19:27] <cjwatson> that means userspace is all done and it's up to the kernel
[19:27] <cjwatson> well, unless it's calling the wrong syscall to power off, but ...
[19:33] <lfaraone> cjwatson: so you're betting that this problem would also occur in an installed system.
[19:34] <cjwatson> that would be my guess. it's always possible I'm wrong
[19:34] <lfaraone> wooh, we have a REGRESSION.
[19:35] <pitti> calc: do you plan to have ooo-langpacks for jaunty? I. e. should I approve the "jaunty" goal proposal?
[19:35] <lfaraone> cjwatson: would it be sufficent for me to ninstall the jaunty kernel on my intrepid install, or should I upgrade fully to test?
[19:36] <calc> pitti: i'm working on it during jaunty but it won't land until jaunty+1 i think
[19:36] <pitti> calc: ok, I decline it as a jaunty goal then
[19:36] <calc> pitti: i'll be working with sun the week after the sprint in hamburg on it
[19:36] <calc> pitti: is there a way to put it for 9.10 already, or just have to leave it unassigned for now?
[19:36] <pitti> calc: the latter, I think
[19:36] <calc> ok
[19:36] <calc> pitti: similiarly the ooo-splitbuild will only be in ppa until jaunty+1
[20:30] <cjwatson> lfaraone: I think the kernel alone should be sufficient
[20:36] <lfaraone> cjwatson: thanks
[20:37] <LaserJock> cjwatson: congrats! I'm glad to have you on the TB
[20:37] <LaserJock> it was very much a win-win situation for us, IMO :-)
[20:40] <cjwatson> Kees would have been an excellent TB member too, in some ways I'm sorry it had to be a choice; perhaps we can rectify that at a later time :-)
[20:40] <LaserJock> definately
[20:40] <pochu> cjwatson, kees: thanks both for running for the position!
[20:41] <pochu> LaserJock: how do you know? I see nothing in u-d-a or u-a
[20:41] <cjwatson> https://launchpad.net/~ubuntu-dev/+polls shows it
[20:42] <pochu> oh, I was looking directly into ~techboard to see if any had been already added to the team
[20:44] <cjwatson> no, I figure somebody will get round to that at some point :)
[21:47] <kees> cjwatson: congratz!  I'm honored to have been nominated, and I'm happy to have you on the TB.  :)
[22:40] <maxb> I filed an NBS bug and subscribed ~ubuntu-archive about 3 weeks ago - should I assume that all the argive admins are tied up with Hardy.2, or should I be wondering if I did something wrong in the bug? (LP 311585)
[22:42] <ScottK> maxb: What are you expecting to happen?
[22:42] <directhex> chorus of angels would be nice
[22:43] <maxb> Well, NBS binaries get removed, right? And for some reason those ones aren't showing up at people.ubuntu.com/~ubuntu-archive/NBS/
[22:43] <maxb> So I thought I should be calling attention to them
[22:44] <slangasek> yes, the bug being filed is helpful - I'm aware of the bug, but didn't get to it on my last couple of archive days
[22:44] <ScottK> OK.
[22:44] <slangasek> (not all the archive admins are tied up with hardy .2, but I am :)
[22:45] <ScottK> slangasek: Any idea why they aren't on the NBS list then?
[22:45] <slangasek> it's helpful to have the bug filed in this case because it's a some-archs-only NBS
[22:45] <ScottK> Ah.
[22:45] <slangasek> the NBS report only detects when the package is gone from debian/control, not when it shifts arch coverage
[22:46] <maxb> Thanks, just wanted to make sure I'd done the right thing with the bug
[23:23] <mathiaz> archive admins: why was the checkbox upload rejected?
[23:26] <mathiaz> Riddell: ^^ nevermind - I've got the answer.