[00:06] <slangasek> seb128: I don't have GTK_IM_MODULE set anymore; the default GTK IM became less inadequate
[00:06] <slangasek> (and if that caused the display of text to be completely changed, someone should be thwapped :)
[00:06] <seb128> slangasek, ok, so I don't know why some people get it and some don't
[00:06] <slangasek> yeah, dunno
[00:18]  * ogra hugs popey for his eternal patience with karl f. larsen
[00:18] <popey> haha
[00:18] <Caesar> Where can I spectate?
[00:20] <ogra> Caesar, ubuntu-users ML
[00:21]  * bigon is wondering is upload that fix #516359 could not also contains fixes for #497497 and #472444
[00:21] <ogra> https://lists.ubuntu.com/archives/ubuntu-users/2010-February/209987.html is worth a read
[00:21] <ogra> and after that thread (but only after) https://lists.ubuntu.com/archives/ubuntu-users/2010-February/210545.html
[00:22] <popey> hehe
[00:23] <ogra> *g*
[00:23] <popey> i had missed that first one
[00:23] <popey> he's calmed down a lot
[00:23] <ogra> karl is my best entertainment on that list, without him i would probably have unsubbed a year ago ...
[00:23] <ogra> sadly he caused so much damage
[00:24] <popey> indeed
[00:24] <ogra> but yes, its a lot better recently
[00:24] <popey> he's on moderation
[00:24] <popey> the only person who is
[00:24] <Caesar> Was he that guy at UDS?
[00:24] <ogra> the fun thing is that re is really rarely offending to anyone
[00:24] <popey> yeah, he's calmed down enough to come off mod i reckon
[00:24] <ogra> but he manages to get perople so far over the edge that *they* get offending
[00:24] <popey> yeah, vicious circle
[00:25] <ogra> watching him is like a psychological study of masses
[00:25] <slangasek> Lucid: now with stubble
[00:25] <popey> that could be said of vast swathes of the ubuntu community
[00:26] <ogra> yeah, indeed, but karl is really special
[00:26] <popey> he's what 75 years old or something?
[00:26] <ogra> resistent to any learning ...
[00:26] <ogra> yeah
[00:26] <ogra> behaving like 12 or so :)
[00:26] <popey> we have a cantankerous old git in our local Linux User Group, he's much the same, but much less gun-ho
[00:26] <popey> he hates ubuntu too :)
[00:26] <ogra> heh
[00:26] <ogra> karl loves it i think
[00:27] <popey> i stuck an ubuntu sticker on the underside of his debian laptop once.. he went mental
[00:27] <ogra> lol
[00:27] <popey> lovely guy, we do love to wind eachother up now and then
[00:28]  * ogra will print "Karl F. Larsen Groupie" t-shirts and hand them out at uds !
[00:28] <ogra> to all ML mods :)
[00:28] <popey> heh
[00:29]  * kees heads head on desk.
[00:29] <kees> every time I get dmsetup export support into Debian, they rip it back out since it is "unused".
[00:30] <slangasek> hmm?
[00:42] <kees> pitti: this is not a 1 day task, I'm about 1/4 of the way done with the devmapper+lvm2 merge, just so you don't duplicate work and start it too.
[00:53] <micahg> Amaranth: that user in the flash bug has been problematic
[00:53] <Amaranth> Yeah, I can see that :)
[00:53] <micahg> Amaranth: I'm talking to LP admins about it now
[01:12] <spm> Amaranth: fyi. I've sent a polite please don't "send as" email; a call from a vaguely irrelevant authority has worked in the past; so hopefully will this time. we shall see.
[03:55] <spenser> Hi, I'm working on fixing bug #520240.  This is my first ever attempt at a patch for Ubuntu/Debian.  I updated the rules and added the file that I needed to add,  however when I run debuild -us -uc to build the package I get the following lintian error. Now running lintian...
[03:55] <spenser> E: libapache2-mod-authz-unixgroup: duplicate-conffile /etc/apache2/mods-available/authz_unixgroup.load
[03:55] <spenser> Finished running lintian. How can I fix this?
[03:56] <arand> spenser: #ubuntu-motu might be more appropriate
[03:56] <spenser> ohh ok thank you
[04:51] <F40PH> !ops
[07:42] <pitti> Good morning
[07:42] <pitti> kees: right, understood; thanks so much for taking care of it!
[07:59] <dholbach> good morning
[08:36] <tkamppeter> mvo, hi
[08:36] <mvo> hey tkamppeter
[08:37] <tkamppeter> mvo, I have changed and uploaded HPLIP
[08:37] <mvo> tkamppeter: ok, I will upload update-notifier, lets see if it works then
[08:38] <tkamppeter> Here is the debdiff of HPLIP, so that you do not need to wait for the upload to finish processing: http://pastebin.ubuntu.com/373777/
[08:48] <siretart> E: Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle.
[08:48] <siretart> known?
[08:49] <siretart> oh, bug #516727, sorry for the noise
[08:49] <tkamppeter> mvo, you can try with the debdiff (http://pastebin.ubuntu.com/373777/) for the case the HPLIP package is not yet ready for yyou to download.
[08:50] <tkamppeter> mvo, please tell me when you have uploaded update-notifier, then I can try with a real printer.
[08:51] <mvo> siretart: *grumpf* again? we had that in every release I think :(
[08:51] <mvo> siretart: thanks, do you have this bug? if so, can you attach /var/lib/apt/dpkg/status and your /etc/apt/sources.list (or mail it to me)?
[08:52] <siretart> mvo: I've just removed openoffice.org-filter-binfilter and am just doing a dist-upgrade
[08:52] <siretart> as for sources.list, plain lucid + some ppas (motumedia + chromium)
[08:52] <mvo> siretart: aha, so its lucid->lucid?
[08:52] <siretart> yes
[08:53] <mvo> ok
[08:53] <siretart> I'm not dist-upgrading that often, every few weeks or so
[09:45] <pitti> cjwatson: are you still working on the gnu-efi merge (bug 488797), or is it okay to sponsor?
[10:35] <frafu> Hi, pitti. As far as I know, you are one of the developers of the dist-utils-extra package; correct? If so, could you please have a look at this: https://answers.edge.launchpad.net/python-distutils-extra/+question/100558  Thanks in advance.
[10:36] <pitti> frafu: will have a look
[10:36] <frafu> thanks
[10:39] <Keybuk> ev: just for clarification, 20100211 doesn't work either
[10:42] <pitti> frafu: answered
[10:42] <frafu> pitti: thanks
[10:49] <ev> Keybuk: indeed, I've fixed the problem in casper and have just been waiting for ftpmaster to catch up so I can build new CDs
[10:50] <Keybuk> sweet
[10:58] <kees> pitti: I'm almost ready with lvm2.
[11:00] <kees> Keybuk: upstream debian chopped up their udev rules for devmapper and lvm2.  I'll need to revisit doing Hardy->Lucid upgrades, but for the moment, things look to be correct, even if it results in 3 udev rules files in lvm2 and 2 in dmsetup.
[11:00] <Keybuk> kees: I didn't think we used upstream or Debian rules?
[11:00]  * Keybuk is pretty sure he wrote the rules in our package
[11:01] <kees> Keybuk: we used upstreams, but heavily heavily modified them.  while walking them trying to find differences, I've mostly convinced myself they're sane now.
[11:01] <kees> Keybuk: the only "new" one is the "trigger vgchange" file.
[11:02] <kees> Keybuk: I'm going to upload this to a PPA first; I don't want to break the world, and there is a ton of changes in it.
[11:03] <kees> Keybuk: changelog looks like this so far: http://paste.ubuntu.com/373861/
[11:03] <Keybuk> have you checked the rules against those shipped in the udev packages?
[11:04] <Keybuk> kees: looks sane
[11:05] <kees> Keybuk: afaict, udev doesn't ship anything for dm devices (including lvm).
[11:05] <Keybuk> rules/packages/64-device-mapper.rules
[11:05] <kees> while Debian's rules are somewhat differently arranged, it seems that the bugs we've been fixing with our rules were being fixed by them as well.
[11:05] <Keybuk> rules/suse/64-device-mapper.rules
[11:06] <Keybuk> cause it'd be worth updating udev with new rules if they're much different
[11:06] <geser> kees: is every case of "undefined reference to `__stack_chk_fail'" valid to add "-fno-stack-protector" or do I need to do more checks?
[11:06] <kees> -rw-r--r-- root/root      2643 2010-02-10 15:36 ./lib/udev/rules.d/55-dm.rules
[11:06] <kees> -rw-r--r-- root/root       767 2010-02-10 17:14 ./lib/udev/rules.d/60-persistent-storage-dm.rules
[11:06] <Keybuk> kees: in the source package, not installed
[11:07] <kees> geser: the reverse.  any time you find "undefined reference to `__stack_chk_fail'", you should find out why the linker is bad.  :)
[11:07] <kees> Keybuk: ah, well, one thing at a time.  :)
[11:07] <Keybuk> kees: "while you're in there" :p
[11:07] <kees> -rw-r--r-- root/root       509 2010-02-10 15:36 ./lib/udev/rules.d/60-persistent-storage-lvm.rules
[11:07] <kees> -rw-r--r-- root/root       272 2010-02-10 17:40 ./lib/udev/rules.d/85-lvm2.rules
[11:07] <kees> -rw-r--r-- root/root       550 2010-02-10 17:41 ./lib/udev/rules.d/56-lvm.rules
[11:07] <kees> these are the ones I'm curious about
[11:08] <kees> our 85-lvm2.rules is the new one
[11:08] <Keybuk> that's the one that runs vgscan/vgchange no?
[11:08] <kees> well, "new" in that it's the watershed/vgchange hammer
[11:08] <kees> but they renamed their rules from lvm2 to lvm
[11:08] <kees> I figured I'd just keep ours as 85-lvm2.rules for sanity
[11:08] <kees> it should probably be called 85-lvm-auto.rules or something
[11:09] <Keybuk> possibly
[11:09] <kees> geser: sometimes it's a sign that you're linking with "ld" instead of "gcc"
[11:09] <geser> kees: I was looking at http://launchpadlibrarian.net/38115510/buildlog_ubuntu-lucid-i386.mknbi_1.4.4-2_FAILEDTOBUILD.txt.gz
[11:10] <kees> geser: ld -N -Ttext 0x92800 -e _start --oformat binary -o first32@0x92800.linux start32@0x92800.o first32.o memsizes.o printf.o string.o
[11:10] <kees> swap ld with gcc for now
[11:10] <kees> if you can
[11:10] <geser> kees: does it make a difference that gcc is called with -ffreestanding?
[11:10] <kees> geser: otherwise, build the .o files with -nostdlib
[11:11] <kees> geser: it should yes, as freestanding uses nostdlib, iirc
[11:13] <geser> kees: in this case building the .o files with -nostdlib would be the right fix, correct?
[11:14] <kees> geser: yeah, I think that would work.
[11:14] <geser> thanks, will try out if this fixes the FTBFS
[11:14] <kees> geser: it's likely a bug that it stackprotector should be disabled when -ffreestanding exists
[11:22] <ogra> Keybuk, bug 520028 ... shouldnt there be a stronger dependency on dbus from upstart (if thats really at fault here)
[11:22] <Keybuk> "stronger dependency" ?
[11:22] <Keybuk> you mean like PRE-DEPENDS
[11:23] <Keybuk> wing-commander scott% dpkg -s upstart | grep dbus
[11:23] <Keybuk> Pre-Depends: libc6 (>= 2.4), libdbus-1-3 (>= 1.2.16), libnih-dbus1 (>= 1.0.0), libnih1 (>= 1.0.0), libudev0 (>= 147), sysvinit-utils, sysv-rc, initscripts, mountall
[11:25] <ogra> Keybuk, libdbus-1-3 only recommends dbus
[11:26] <ogra> and apparently that guy has a prob if dbus isnt installed (which doesnt happen with plain debootstrap)
[11:26] <StevenK> cjwatson: My shell foo is failing me, can "run this, and then this, and if either one of them is successful, run this other thing" be expressed?
[11:28] <Keybuk> ogra: upstart doesn't depend on dbus (the daemon) though
[11:28] <ogra> Keybuk, if the daemon is essential for booting i think it should be either pulled in by debootstrap or by upstart
[11:28] <Keybuk> it's not essential for booting
[11:29] <Keybuk> the fact you can install ubuntu-minimal with debootstrap and go is a good sign here
[11:29] <Keybuk> it means that whatever he's using (which is not debootstrap, the bug is on something called "project-rootstock") is failing to build a correct image
[11:29] <ogra> rootstock is a wrapper to debootsrap
[11:30] <ogra> (and a bit more)
[11:31] <Keybuk> the deps are correct, anyway
[11:31] <Keybuk> upstart pre-depends libdbus
[11:31] <Keybuk> libdbus recommends dbus
[11:31] <Keybuk> the dbus daemon is not a requirement, but is present in all but unusual situations
[11:31] <Keybuk> which is the correct meaning
[11:31] <ogra> define an unusal situation :)
[11:31] <Keybuk> stripped down installs
[11:31] <Keybuk> embedded platforms
[11:32] <Keybuk> highly focused specialised things
[11:32] <ogra> if he just runs debootstrap (which he essentially did) then dbus is apparently missing
[11:32] <Keybuk> sure
[11:32] <Keybuk> nothing wrong with that
[11:32] <ogra> i would expect debootstrap to create a basic functional system
[11:33] <Keybuk> it does
[11:34] <ogra> ogra@osiris:~/Devel/branches/project-rootstock$ sudo chroot /var/build/lucid-arm-chroot/ dpkg -l dbus|grep ^ii
[11:34] <ogra> ogra@osiris:~/Devel/branches/project-rootstock$
[11:34] <Keybuk> you know what
[11:34] <Keybuk> why do you bother asking me things?
[11:34] <Keybuk> you never listen to my answers
[11:34] <Keybuk> I've said four times that you don't need the dbus daemon
[11:34] <Keybuk> and yet you continue to ignore me
[11:34] <ogra> ok, sorry
[11:35] <Keybuk> I'll explain it one more time
[11:35] <Keybuk> Upstart uses peer-to-peer D-Bus
[11:35] <ogra> no, its ok
[11:36] <Keybuk> when you want to talk to Upstart, you open an AF_UNIX socket and connect to @/com/ubuntu/upstart
[11:36] <Keybuk> the protocol you talk is the D-Bus protocol
[11:36] <Keybuk> as implemented by libdbus
[11:36] <Keybuk> but there is no bus daemon involved
[11:36] <Keybuk> the thing listening on that socket is init itself
[11:36] <Keybuk> this means that the D-Bus daemon (in the dbus package) is not required
[11:36] <Keybuk> you *can* also use the D-Bus daemon if you prefer
[11:36] <Keybuk> if it's running, Upstart will connect to it
[11:36] <Keybuk> and then you can use libdbus to open a bus connection (to the system bus)
[11:36] <Keybuk> and address messages to com.ubuntu.Upstart on that
[11:37] <Keybuk> and reach the init daemon
[11:37] <Keybuk> the advantage of doing this is that since the bus daemon is an intermediary, you can do this as non-root
[11:37] <Keybuk> the bus daemon security policy permits read-only queries
[11:37] <Keybuk> this is why "status", "initctl list", etc. all work as normal users
[11:37] <Keybuk> but "stop", "start", etc. don't
[11:37] <Keybuk> so
[11:37] <Keybuk> while you need libdbus
[11:37] <Keybuk> you do not *need* dbus
[11:38] <Keybuk> and since the entire boot is done as root, nothing will try and use it anyway
[11:38] <ogra> right, understood
[11:38] <Keybuk> mountall uses this peer-to-peer connection too
[11:38] <Keybuk> fwif
[11:38] <Keybuk> so it only needs libdbus, not dbus-daemon
[11:39] <Keybuk> you only need dbus if you want system bus services, like Network Manager, or Avahi, etc.
[11:39] <Keybuk> but since those aren't part of minimal, you don't get the bus daemon
[11:39] <ogra> right, and they usually depend on the daemon if there is no packaging error
[11:40] <ogra> Keybuk, thanks a lot for that intro, i really didnt mean to annoy you
[11:41] <Keybuk> exactly
[11:41] <Keybuk> since I know for a fact that ubuntu-minimal works
[11:41] <Keybuk> and he doesn't say anywhere how "boot doesn't work"
[11:41] <Keybuk> and is using a non-standard way of building it
[11:41] <Keybuk> I'm inclined to believe he's screwed up
[11:41] <ogra> right
[11:41] <Keybuk> I'm also quite happy to be proved wrong here ;)
[11:41] <ogra> well, he is using a bare debootstrap
[11:41] <ogra> thats what rootstock does if you dont specify anything extra
[11:42] <cjwatson> pitti: I don't think I was ever working on it - my comment just meant what it said on the tin
[11:42] <cjwatson> pitti: feel free to sponsor
[11:43] <ogra> i used to install ubuntu-minimal by default on top of that if you dont use any options ... but that was removed at some point by lool (i think to gain debian compatibility), i'll re-add it
[11:43] <Keybuk> I'm not 100% sure a bare debootstrap boots
[11:43] <Keybuk> you'd have to check with cjwatson on that one
[11:44] <Keybuk> I can't remember what debootstrap actually installs
[11:44] <kees> cjwatson: hi! in doing the devmapper/lvm2 merge I ran into a change you made that I think is no longer needed, but I wasn't sure how to validate it for sure.
[11:44] <kees> cjwatson: you set DH_OPTIONS="" before doing the shlibs build to get sane symbols for udebs.  I think this is fixed upstream, but I don't know quite what to look for.
[11:46] <cjwatson> StevenK: there might be a more concise way, but I would write it as something like:  CODE1=0; command1 || CODE1=$?; CODE2=0; command2 || CODE2=$?; if [ "$CODE1" -eq 0 ] || [ "$CODE2" -eq 0 ]; then command3; fi
[11:47] <cjwatson> Keybuk,ogra: debootstrap installs priority: required and important; dbus is priority: optional
[11:47] <ogra> right
[11:47] <cjwatson> Keybuk,ogra: debootstrap certainly installs ubuntu-minimal, unless something went wrong
[11:48] <ogra> well, not the metapackage, does it ?
[11:48] <cjwatson> yes, the metapackage
[11:48] <ogra> ok
[11:48] <cjwatson> apt-cache show ubuntu-minimal | grep ^Priority:
[11:48] <ogra> :)
[11:48] <ogra> important ... ok
[11:48] <Keybuk> cjwatson: ok, so debootstrap output should boot
[11:49] <ogra> Keybuk, it usually does for me
[11:49] <Keybuk> ogra: I'm going to ask a very pertinent question
[11:49] <cjwatson> we stopped hardcoding the list of packages to use for debootstrap in 2005; it's all priority-driven nowadays
[11:49] <ogra> but that user seems to be on karmic
[11:49] <Keybuk> which may reveal how silly the reporter is being
[11:49] <Keybuk> he installed debootstrap
[11:49] <Keybuk> ...
[11:49] <cjwatson> kees: let me check ...
[11:49] <Keybuk> did he install a kernel as well?
[11:50] <Keybuk> and a boot-loader?
[11:50] <kees> cjwatson: specifically this: http://launchpadlibrarian.net/16954645/devmapper_2%3A1.02.25-1ubuntu4_2%3A1.02.25-1ubuntu5.diff.gz
[11:50] <ogra> Keybuk, well, thats up to the user with rootstock ... but apparently after installing dbus his system booted ... who knows what he did inbetween first boot and dbus
[11:50] <cjwatson> yeah, I was just tracking down the changelog to refresh my memory
[11:50] <cjwatson> I certainly remember why that was needed, so I'll double-check Debian
[11:50] <kees> cjwatson: what should I look for in the udebs?
[11:51] <Keybuk> ogra: which makes no sense
[11:51] <slangasek> cjwatson: CODE1=... eew, let's not have that in antimony's crontab please :)
[11:51] <kees> cjwatson: the debian build of libdevmapper* in lvm2 is now very different
[11:51] <Keybuk> an ubuntu-minimal install basically consists of upstart, udev, mountall and getty
[11:51] <ogra> Keybuk, ??
[11:51] <ogra> right
[11:51] <Keybuk> that boots perfectly, *really fast* :p
[11:51] <cjwatson> kees: you actually want to look at the shlibs file in the run-time library's control area
[11:51] <cjwatson> and make sure it has some plausible-looking udeb: entries
[11:52] <kees> debdiff between old and new libdevmapper1.02.1-udeb don't show regressions there, but let me unpack it and actually look at it
[11:52] <cjwatson> you won't see it when debdiffing the udeb
[11:52] <cjwatson> the breakage was exposed by building other udebs against devmapper
[11:53] <kees> hrm, perhaps I don't know what "run-time library's control area" is
[11:53] <cjwatson> libdevmapper1.02.1 rather than libdevmapper1.02.1-udeb
[11:53] <slangasek> the DEBIAN/shlibs file, which won't register on debdiff
[11:53] <kees> oh! er, okay
[11:54] <kees> ah-ha, yes.  my current merge breaks it.
[11:54] <cjwatson> so, err ... the Debian mirror I'm looking at doesn't actually appear to have a current libdevmapper1.02.1-udeb
[11:54] <StevenK> Hah, damn. slangasek guessed what I wanted it for ;-)
[11:55] <slangasek> StevenK: the mail from lool was a clue
[11:55] <cjwatson> it builds clvm, lvm2-udeb, and lvm2
[11:55] <kees> ah-ha, I just missed it, it does show in the debdiff of the regular debs, oops.
[11:55] <cjwatson> am I missing something obvious?
[11:56] <kees> libdevmapper 1.02.1 [-libdevmapper1.02.1-] {+libdevmapper-event1.02.1+} (>= [-2:1.02.27)-]
[11:56] <kees> [-udeb: libdevmapper 1.02.1 libdevmapper1.02.1-udeb (>= 2:1.02.27)-] {+2:1.02.39)+}
[11:56] <kees> how to fix this in the current merge is not immediately obvious, though.
[11:57] <cjwatson> slangasek: if you have a cleaner answer to the question asked ...
[11:57] <slangasek> cjwatson: I want to revisit the premise :)
[11:57] <cjwatson> well, I sort of agree there, if this is imx51/dove stuff
[11:57] <kees> fwiw, current package looks like this: https://edge.launchpad.net/~kees/+archive/ppa/+sourcepub/962485/+listing-archive-extra
[11:57] <cjwatson> the fact that doing those builds involves two separate invocations is a bug in and of itself
[11:57] <cjwatson> and I said so from the beginning, I think
[11:57] <slangasek> StevenK, lool: the whole reason we're running this as two commands instead of one was to work around some armel buildd bug... do we know that this is still an issue?
[11:58] <dholbach> does anybody know what I should be doing if "bzr merge-package <...>" says "ERROR: No such tag: upstream-2.0.3"?
[11:58] <dholbach> james_w maybe^ :)
[11:58] <StevenK> slangasek: I'm doing it as two seperate builds since I didn't want imx51 to impact on dove and vis-vrsa
[11:58] <cjwatson> eww, libdevmapper* has a different set of version numbers, no wonder I missed it
[11:58] <StevenK> *vise versa
[11:58] <kees> cjwatson: mind bending :)
[11:59] <cjwatson> kees: Debian's package seems to have correct shlibs
[11:59] <cjwatson> libdevmapper 1.02.1 libdevmapper1.02.1 (>= 2:1.02.39)
[11:59] <cjwatson> udeb: libdevmapper 1.02.1 libdevmapper1.02.1-udeb (>= 2:1.02.39)
[11:59] <slangasek> dholbach: you're supposed to be able to fall back on bzr merge
[11:59] <kees> cjwatson: perhaps it's the addition of libdevmapper-event that is breaking it
[11:59] <dholbach> slangasek: "ok"
[11:59] <slangasek> StevenK: er, and what makes you think that running them as a single command will cause them to "impact" each other?
[12:00] <cjwatson> kees: ah yes, that's quite possible
[12:00] <StevenK> slangasek: So, "ARCHES='armel+imx51 armel+dove' buildlive" ?
[12:00]  * kees tries the DH_OPTION=  fix...
[12:00] <cjwatson> wisdom teeth are impacted, people are affected by the effects of events
[12:00] <cjwatson> as a .sig I saw once said
[12:02] <kees> cjwatson: hmpf, no love.
[12:02] <slangasek> StevenK: ARCHES='armel+imx51 armel+dove' buildlive ubuntu-netbook && ARCHES='armel+imx51 armel+dove' for-project ubuntu-netbook cron.ports_daily-live - but again, I was told the original reason for the split was to work around some strange autobuilder bug
[12:02] <slangasek> s/autobuilder/livefs buildd/
[12:03] <StevenK> I'm happy enough to try that and see what happens
[12:03] <ogra> yes, while clementine is supposed to serialize builds that apparently doesnt work right
[12:03] <StevenK> Er, it has, and does
[12:03] <StevenK> Because I've seen it, multiple times
[12:04] <ogra> well, if you are confident. go ahead and try it
[12:04] <StevenK> Hopefully that will make lool happy too
[12:04] <ogra> i know we had issues in the past which initially resulted in that weird crontab entry
[12:13] <cjwatson> kees: do you have a bzr branch or something I can check out?
[12:13] <cjwatson> or should I just use source from your ppa?
[12:14] <kees> cjwatson: I can create one, if you want, but go ahead and snag the source from my ppa.
[12:14] <cjwatson> kees: and did you literally try DH_OPTION=, or the correctly spelled DH_OPTIONS=?
[12:14] <kees> I'm about 5 hours overdue for bedtime.  ;)
[12:14] <kees> cjwatson: it was the correctly spelled DH_OPTIONS=
[12:14] <kees> cjwatson: what's melting my mind now is how what's in the built deb got there.
[12:14] <kees> libdevmapper 1.02.1 libdevmapper-event1.02.1 (>= 2:1.02.39)
[12:14] <kees> that's in libdevmapper
[12:14] <kees> yet...
[12:15] <kees> it's in no shlibs file in the build tree
[12:15] <cjwatson> dpkg-checkbuilddeps: Unmet build dependencies: libreadline5-dev
[12:15] <cjwatson> don't suppose that's easily upgradeable to readline6?
[12:15]  * cjwatson hates having to switch back and forth
[12:15] <kees> $ cat ./debian/libdevmapper1.02.1/DEBIAN/shlibs
[12:15] <kees> libdevmapper 1.02.1 libdevmapper1.02.1 (>= 2:1.02.39)
[12:15] <kees> udeb: libdevmapper 1.02.1 libdevmapper1.02.1-udeb (>= 2:1.02.39)
[12:15] <kees> *hold face*
[12:16] <kees> cjwatson: I can try it with 6
[12:19] <cjwatson> kees: build in progress here
[12:20] <kees> cjwatson: it built fine with readline6, so I'll flip that.
[12:20] <kees> this is _really_ odd.  what is changing the shlibs file between debian/libdevmapper1.02.1/DEBIAN/shlibs and the deb
[12:26] <kees> cjwatson: aargh, I'm an idiot. DH_OPTIONS=  worked fine, I just changed my version for the PPA upload. so I had ubuntu1 and ubuntu1~kees1 .debs.  I was checking the wrong one.
[12:26] <Keybuk> ev: Executing grub-install hd(0) failed.  This is a fatal error.
[12:26] <kees> s/an idiot/way past bedtime/
[12:27] <ev> bah
[12:27] <kees> okay, uploading the fix to my PPA, heading to bed
[12:27] <cjwatson> kees: ah, ok :)
[12:27] <ev> Keybuk: did you change your preseed?  Surely that should be grub-install (hd0)
[12:27] <Keybuk> ev: err, (hd0) is what it said
[12:27] <Keybuk> was retyping without paying complete attention
[12:28] <Keybuk> syslog says "no mapping exists for 'hd0'"
[12:28] <cjwatson> kees: I tend to use DH_VERBOSE=1 pretty liberally for debugging this kind of thing
[12:29] <cjwatson> Keybuk: clearly a bug, but can you use /dev/sda rather than (hd0)?
[12:30] <cjwatson> we're finally managing to get on the road to deprecating (hdX,Y) names for most purposes
[12:30] <cjwatson> and it might work around whatever the problem is
[12:30] <Keybuk> cjwatson: how do I do that?
[12:31] <Keybuk> ubiquity        partman-auto/disk       string  /dev/sda
[12:31] <ev> grub-installer/bootdev /dev/sda
[12:31] <Keybuk> is what I have in my seed
[12:31] <Keybuk> ev: I don't have anything about grub in there right now?
[12:31] <ev> Keybuk: indeed, this is a workaround for the aforementioned bug
[12:31] <cjwatson> huh
[12:32] <cjwatson> why is (hd0) turning up at all then
[12:32] <cjwatson> # Try to avoid using (hd0) as a boot device name.  Something which can be
[12:32] <cjwatson> # turned into a stable by-id name is better.
[12:32] <cjwatson> default_bootdev_os="$($chroot $ROOT grub-mkdevicemap --no-floppy -m - | head -n1 | cut -f2)"
[12:32] <cjwatson> it only uses (hd0) if that fails
[12:33] <Keybuk> you want the full logs?
[12:33] <cjwatson> Keybuk: yes please, and could you also run 'chroot /target grub-mkdevicemap --no-floppy -m -' from a shell prompt after the failure and see what it says?
[12:34] <cjwatson> maybe I forgot to mount /proc and friends before calling grub-mkdevicemap
[12:38]  * ogra wonders how to tell jockey to not sacn on every start 
[12:38] <ogra> *scan
[12:40] <lool> StevenK, ogra, slangasek: Only the buildlive calls need to be split though, not the cron-ports.daily-live one
[12:41] <ogra> yes
[12:42] <slangasek> lool: but it's precisely that splitting that makes it a PITA to check the return code
[12:44] <cjwatson> right; if it absolutely has to be serialised for some reason, that serialisation needs to be done inside the buildlive script itself
[12:44] <cjwatson> but I would hope that isn't really necessary
[12:44] <lool> slangasek: I don't think it's particularly bad if we run the image building code if the livefs failed
[12:44] <cjwatson> we need to be consistent about this across architectures.  it's a pain for armel to be substantially different
[12:45] <Keybuk> cjwatson: http://people.canonical.com/~scott/daily-installer/20100211.1-max/
[12:45] <lool> IMO the easiest way is to add a livefs builder..
[12:45] <Keybuk> that has the syslog and stuff
[12:45] <slangasek> lool: even if it causes previous successful builds to be rotated off?
[12:45] <ogra> lool, ++ send hardware :P
[12:45] <lool> That would make things more symetric and would alleviate the image building time for armel....
[12:45] <cjwatson> lool: why can't we just run the two live filesystem builds in parallel?
[12:45] <lool> slangasek: It shouldn't be a failed build
[12:45] <slangasek> lool: want to give up a buildd to do it? :)
[12:46] <cjwatson> sure, it takes longer, but it takes longer *anyway* right now
[12:46] <lool> cjwatson: we only have one livefs builder, and it happened that the serialization code didn't work
[12:46] <Keybuk> cjwatson: running the chroot grub-mkdevicemap outputs
[12:46] <ogra> cjohnston, because the build machine is already underpowered
[12:46] <Keybuk> (hd0) /dev/sda
[12:46] <lool> But it was years ago, perhaps that would work now
[12:46] <lool> I never got the chance to debug it
[12:46] <cjwatson> ogra: we're already running two builds
[12:46] <slangasek> no, it wouldn't be a failed build, it would just be an ISO that's identical to the previous build and therefore redundant
[12:46] <ogra> years ?
[12:46] <lool> the symptom was that the livefs buildd was stuck
[12:46] <ogra> right
[12:46] <cjwatson> ogra: it makes no logical difference to underpoweredness whether we fire off two builds at once and have one stick on a lock until the other's done, or explicitly serialise them
[12:46] <cjwatson> so this is a red herring
[12:46] <ogra> cjwatson, yes, i know, but we cant run them at the same time
[12:46] <lool> slangasek: Yeah, and I don't have a big problem with that!
[12:46] <slangasek> cjwatson: the failure mode was that the livefs buildd required a hard reset
[12:47] <cjwatson> ogra: livecd.sh doesn't try though, it uses locks
[12:47] <lool> (hard reset == someone goes to data center to reboot)
[12:47] <cjwatson> slangasek: right, but I'd much rather we debugged that ...
[12:47] <slangasek> certainly
[12:47] <cjwatson> Keybuk: permission errors on syslog
[12:47] <ogra> cjwatson, we have no control about the kernel on these machines and its not a good kernel ...
[12:48] <Keybuk> cjwatson: bah
[12:48] <Keybuk> I keep fixing that
[12:48] <ogra> i.e. it produces unexpected lockups in several cases
[12:48] <lool> I don't mind trying the lock thing again; I still believe the best thing which can happen is a second livefs builder
[12:48] <ogra> yes
[12:48] <ogra> its the only proper solution
[12:48] <cjwatson> I have no objection to a second livefs builder.  I do object to the way the scripts are laid out right now
[12:48] <ogra> but we lack HW for that
[12:48] <Keybuk> cjwatson: try now?
[12:48] <cjwatson> it's confusing and error-prone
[12:48] <lool> I had objections too  :)
[12:48] <cjwatson> Keybuk: better, thanks
[12:48] <lool> We could do locking on the cdimage side
[12:49] <slangasek> lool: well, I have a problem with us stomping on history that would've been useful to retain when it's avoidable
[12:49] <cjwatson> lool: I don't really care how it's done as long as it is done by a single invocation of buildlive
[12:49] <lool> slangasek: What we care about in this situation is fixing the image build anyway, don't we?
[12:49] <lool> (s/image/livefs)
[12:49] <cjwatson> not necessarily if we're in the last day or two of the release process
[12:49] <slangasek> that's not the *only* thing to care about, no
[12:50] <Keybuk> ah, I fixed it in success.sh not in failure.sh
[12:50] <cjwatson> in that circumstance, sometimes the right thing to do is simply to back off
[12:50] <slangasek> cjwatson: OTOH, in the last day or two all builds are manual :)
[12:50] <cjwatson> yes, but the less weird shell you have to deal with, the better ...
[12:50]  * slangasek nods
[12:50] <cjwatson> complex => error-prone
[12:50] <lool> Anyway, we all agree on what the ideal situation would be, we just have various levels of tolerance with intermediate fixes
[12:51] <ogra> and we dont have any hard data atm ...
[12:51] <lool> So, let's try to get another builder, let's try to have a single buildlive call perhaps doing local locking, and let avoid building images when the livefs failed to build
[12:51] <ogra> lets try with a single buildlive run and see what happens first
[12:51] <slangasek> is there sufficient buildd capacity to consider repurposing a buildd as a second livefs builder?
[12:52] <ogra> hostorically it didnt, but we lose only one daily build if it doesnt now
[12:52] <ogra> slangasek, no
[12:52] <ogra> thats the point
[12:52] <ogra> we lack HW
[12:53] <lool> Anyway, my involvment was just in raising a flag that cron.ports-daily-live should only run once for the same project, that has been well covered; I think I'm just adding confusion in the discussion now, I'll mobile / IS to resolve
[12:53] <lool> +let
[12:53]  * lool lunch &
[12:53] <slangasek> local locking> I don't see the point it doing that (also error-prone) rewriting when the builder-fall-down-go-boom problem should be fixed anyway
[12:54] <slangasek> ogra: "we lack HW" doesn't say anything about the buildd capacity to me
[12:54] <slangasek> since the running buildds are obviously hardware that exists, and therefore is not lacked :)
[12:54] <ogra> we have 8 buildds for everything and one livefs builder
[12:54] <ogra> of these buildds usually one or two are hung
[12:54] <ogra> and we are usually constantly behind
[12:54] <slangasek> ok.
[12:55] <ogra> oh, and buildds need to be in manual for several reasons as well, i.e. team PPA builds etc
[12:55] <ogra> so in average we operate with 4-5 maichine plus livefs machine
[12:55] <ogra> *machines
[12:56] <slangasek> so the fact that armel's build queue is currently empty is atypical?
[12:56] <ogra> yes
[12:56]  * slangasek nods
[12:56] <ogra> but more than the queue the factz that packages take about twice as long to build on our buildds is more significant
[12:57] <slangasek> not really
[12:57] <ogra> like a mass give back of KDE can take us out of business for two days
[12:57] <slangasek> adding or removing a builder wouldn't change that
[12:57] <ogra> having uploads qeueing up
[12:58] <ogra> i foten have uploads sitting there for half a day because of toochain testbuilds while OO.o builds, while some kde package builds ... so the queue is processed a lot slower
[12:58] <ogra> *often
[13:11] <mdeslaur> slangasek: curiously, after updating packages at the sprint, I did get a plymouth splash screen with nvidia binary drivers for a couple of days, and then it went away again...
[13:12] <slangasek> mdeslaur: that might have corresponded to a window when grub2 was doing Mad Things by default
[13:12] <slangasek> (gfxpayload=keep)
[13:13] <mdeslaur> slangasek: ah, maybe. mad, but nice looking. :)
[13:13] <slangasek> if only that were the effect that option had for /everyone/, that would be great. :)
[13:13] <mdeslaur> hehe
[13:14] <dholbach> ara: do you want 516248 reviewed too?
[13:15] <ara> dholbach, that one is fix released
[13:15] <dholbach> ara: the merge proposal is still around - I'll mark it merged
[13:16] <dholbach> hum, or maybe I don't
[13:16] <dholbach> not sure who has the power to do it
[13:19] <dholbach> ara: maybe you can mark it merged or something
[13:19] <ara> dholbach, I'll try
[13:20] <dholbach> fantástico
[13:21] <ara> dholbach, I can't, either
[13:21] <dholbach> bah
[13:21] <dholbach> maybe mark the branch as merged?
[13:22] <dholbach> if not maybe james_w can help
[13:22] <james_w> what's the url?
[13:22] <james_w> there's an open bug about this
[13:24] <dholbach> https://code.edge.launchpad.net/~apulido/ubuntu/lucid/ldtp/ldtp-fix-516248/+merge/18476
[13:30] <dholbach> james_w: having any luck?
[13:35] <slangasek> Riddell: why is virtuoso-opensource-6.0 using Pre-Depends when it doesn't have a preinst?
[13:41] <dholbach> can somebody have a look at bug 506908 and see if the upstart script is good and upload it?
[13:42] <dholbach> ara: seems like james_w managed to fix it somehow :)
[13:42] <ara> dholbach, james_w: thanks!
[13:43] <james_w> ara: you can me-too bug 504025 about this if you like
[13:43] <dholbach>  /me me-toos too
[13:45] <ara> james_w, done :)
[13:50] <apw> pitti, isn't the work-items-tracker meant to support dropped now?
[13:51] <apw> ERROR: kernel-lucid-kernel-config-review: invalid state "dropped" for work item "[apw] Master config support from master branch in other branches"
[13:51] <pitti> apw: hm, it's supposed to, I'm using it myself
[13:51] <apw> i am somewhat confused cause i see it in the code
[13:52] <apw>     if state in ('postpone', 'dropped', 'drop'):
[13:52] <apw>         state = 'postponed'
[13:52] <apw> i'd have expected that to zap it
[13:52] <pitti> right, it should
[13:52] <pitti> apw: you get that as email?
[13:52] <apw> pgraner did ... i'll check if i did too
[13:52] <apw> yeah last night
[14:18] <sebner> cjwatson: alien-arena is blocked on buggy dpkg. I heard you plan to merge dpkg?
[14:19] <persia> Um, I only said that a merge of dpkg was mentioned  I didn't mean to imply that any specific person was planning to do it.
[14:19] <cjwatson> sebner: I plan to do that after bzr-builddeb can cope with importing .tar.bz2
[14:19] <sebner> *hohohoho*
[14:19] <cjwatson> which james_w is in the process of doing, I understand
[14:20] <sebner> cjwatson: take my thanks then :)
[14:20] <cjwatson> I'm not expecting the merge to be hugely difficult, but I don't want to do it outside bzr unless I have no other choice
[14:20] <sebner> persia: Don't you feel like a cattleman? :P
[14:20] <persia> sebner: No.
[14:21] <sebner> cjwatson: no problem. As long it happends before FF ..
[14:21] <sebner> persia: pushing me around that much *hehehe*
[14:21] <pitti> apw: btw, any luck with the usb_id delay thing? was it that one commit you suspected?
[14:31] <uniscript> anyone planning to package openoffice 3.2 for backporting (karmic)?
[14:32] <uniscript> or should I use release debs from openoffice?
[14:34] <smoser> hi, i'm looking for some feedback.
[14:34] <smoser> Background info: Our UEC/EC2 Images are filesystem images (ext3) as such, we create the filesystem in our build process.
[14:35] <smoser> the filesystem images currently have:
[14:35] <smoser> (per dumpe2fs):
[14:35] <smoser> Maximum mount count:      39
[14:35] <smoser> Last checked:             Thu Feb 11 02:19:12 2010
[14:35] <smoser> Check interval:           15552000 (6 months)
[14:36] <smoser> I suspect that that means an instance of this image booted 6 months from now will run fsck on first boot
[14:36] <bdrung> dholbach: why does sponsors-page.py needs so long (8 mins)? can it somehow accelerated by caching or something else?
[14:36] <persia> smoser: That seems likely, yes.
[14:36] <smoser> fsck'ing on first boot just because time has passed seems like a bad thing, as the bits haven't rotted sitting unused.
[14:37] <smoser> so i'm thinking to 'tune2fs' that off
[14:37] <smoser> anyone have thoughts as to how bad an idea that would be?
[14:37] <dholbach> bdrung: it caches already
[14:37] <persia> smoser: So just fsck based on maximum mount count?  In a UEC enviornment, how often do mounts happen?
[14:37] <dholbach> bdrung: launchpadlib caches automatically
[14:37] <dholbach> bdrung: but if you find a way to speed it up, that'd be cool
[14:37] <ion> smoser: Might or might not be usable for you, but i’m using http://github.com/ion1/e2croncheck to avoid the fsck-on-startup on my server.
[14:38] <dholbach> bdrung: one solution would be: make the list shorter!
[14:38] <bdrung> dholbach: the second run took the same amount of time.
[14:38] <ion> smoser: And also to get quicker notification of potential filesystem problems.
[14:38] <smoser> persia, i think mounts probably occur similarly to "normal" systems. if different, i'd expect that UEC instances would have a shorter lifespan, though. so less mounts.
[14:39] <persia> smoser: My worry was that with fewer mounts, it may be a very extended period of time until fsck.
[14:39] <persia> Maybe the mount count could be reduced if the check interval is removed.
[14:40] <smoser> hm... well, when i said "less mounts", i really meant less mounts ever
[14:40] <smoser> as in the system likely is booted and does some stuff, then the filesystem thrown away
[14:41] <smoser> one thing i *could* do is disable interval checking in the filesystem on creation
[14:41] <smoser> and on first boot turn it on
[14:41] <smoser> if that would cause the first interval based check to occur 'interval' from "now"
[14:41] <persia> smoser: That seems like a reasonable compromise, as long as you have some way to indicate that a check happened on creation.
[14:41] <smoser> persia, a check happend on creation?
[14:42] <persia> smoser: For interval checking to work, you need some "last check" timestamp.  You want to spoof this with the timestamp for system initialisation.
[14:43] <smoser> ah.
[14:43] <bdrung> dholbach: making the list shorter is the best solution. :)
[14:43] <smoser> tune2fs -T will let me set that
[14:43] <dholbach> bdrung: WORD
[14:43] <persia> smoser: There you go then :)
[14:44]  * dholbach advertises: http://qa.ubuntu.com/reports/sponsoring/
[14:44] <smoser> assuming it works on a mounted filesystem
[14:44] <apw> pitti, when i tried to reproduce the usb_id delay, it was not visible in my output
[14:44] <apw> pitti, meant to ask if you were still seeing it
[14:45] <pitti> apw: I'm currently upgrading, I'll try again with -13
[14:45] <pitti> apw: was still there with -12
[14:45] <bdrung> dholbach: WORD?
[14:45] <pitti> apw: http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100209-1-une.png
[14:45] <apw> i thought it had moved down the bottom and was 5s long and jut could not see it
[14:45] <pitti> apw: (note that it doesn't actually hold up the entire session any more since plymouth is now run in parallel; but the 5 second I/O block is still there)
[14:46] <apw> right but its clearly 5s long in your stuff there
[14:46] <pitti> so it "just" slows down boot a little bit, but doesn't stall it by 5s any more
[14:46] <apw> and wasn't there n mine, well it was more like .2s
[14:46] <pitti> apw: either it's causing or waiting on this khubd block
[14:46] <dholbach> bdrung: I very much agree with you :)
[14:47] <smoser> please, if anyone has been following and thinks turning off inteval checking of a filesystem is a 'really bad idea', please speak up.  the *intent* will be to turn it back on on first boot, but that could fail.  The mount-count based checking will still be there.
[14:48] <pitti> davmor, cjwatson: FYI, jockey fix uploaded (for the "always pops up" bug)
[14:48] <bdrung> dholbach: you make the list longer by adding branches to them.
[14:49] <dholbach> bdrung: james_w asked me to
[14:49] <apw> pitti, thats mine: http://people.canonical.com/~apw/misc/penfold-lucid-20100210-2.png
[14:49]  * pitti just finished sponsoring 11 packages and cleanign some 10 bugs, but doesn't see a noticeable dent in the page; *sigh*
[14:49] <apw> but that is with a -13.18 prerelease kernel
[14:50]  * apw sends pitti some red-bull
[14:50] <bdrung> dholbach: can we generate the page dynamically?
[14:50] <pitti> apw: that's a strange one
[14:50] <dholbach> bdrung: like how?
[14:50] <pitti> apw: no gnome-panel, etc? Apparently you don't have an ureadahead pack, so it's smeared out
[14:50] <apw> pitti, note that with a manual login
[14:50] <pitti> but indeed it's not there
[14:51] <bdrung> pitti: thanks for sponsoring lintian.
[14:51] <pitti> apw: ah, it finished dist-upgrading now; rebooting and crossing fingers :)
[14:51] <apw> and yes it may have been making one
[14:51] <mvo> DktrKranz: hi, could you please merge the gdebi debian bzr tree from lp:gdebi? hm, is that tree not a branch from the ubuntu tree? I thin kwe need fiddle wit hthat a bit to make merging work
[14:51] <apw> i'll reboot and get a fresh one
[14:51] <dholbach> bdrung: I think it'd be better to use harvest for things like that (so we just re-use the sponsoring.csv file)
[14:51] <dholbach> bdrung: and when I say harvest, I mean lp:harvest and not the crappy thing that is online right now :)
[14:52] <bdrung> dholbach: i thought at something like we did the dynamic part in harvest. having data prepared in some one and generating the html file dynamically.
[14:52] <cjwatson> pitti: ah, thank you
[14:52] <bdrung> dholbach: http://qa.ubuntu.com/reports/sponsoring/?user=bdrung should show the item that i can sponsor
[14:53] <dholbach> bdrung: the new harvest uses django which will make it a lot easier to create whatever custom views we think of
[14:53] <persia> I think we ought separate specific sponsorship requests from arbitrary things that need review.
[14:54] <bdrung> if harvest can show only sponsoring task, then we should work on harvest and keep the current version of http://qa.ubuntu.com/reports/sponsoring/ as it is now
[14:54] <pitti> apw: nope, still there on -13 :(
[14:54] <apw> pitti, wtf, our machines should be identicle ...
[14:54] <dholbach> bdrung: just check harvest out, set it up like in the INSTALL file and you'll see: it can show different "opportunity types"
[14:54] <DktrKranz> mvo: do you mean to have a common ancestor?
[14:55] <pitti> apw: do you have an even newer kernel than -13?
[14:55] <mvo> DktrKranz: yes, it woudl make merging from and too simpler
[14:55] <pitti>  apw: I don't have anything attached to this thing except the power cable
[14:56] <mvo> DktrKranz: unless of course trunk/ has everything from the debian tree, then I can upload trunk/ to debian
[14:56] <dholbach> bdrung: there's a few things that'd be good to have before we put it online somewhere (I started milestoning bugs against it)
[14:56] <apw> pitti, its in theory the same bits ... i have just realised i do have an MMC card in the thing
[14:56] <apw> and that is on USB ... perhaps thats skewing things
[14:56]  * apw boots again
[14:57] <pitti> apw: there's one thing I changed in the BIOS: It prefers to boot from USB (so that I don't always have to catch the F12 boot screen)
[14:57] <DktrKranz> mvo: I thought it already had, I was probably wrong. I'll convert it later this evening, thanks
[14:57] <pitti> apw: but when I boot -10, it doesn't happen, and with -11 it does happen, so I don't think it's related
[14:57] <apw> pitti, got it ... putting the MMC card in the slot makes it go away
[14:57] <apw> pitti, no wonder i couldn't see it
[14:58] <pitti> magic
[14:58] <apw> ok ... i can go test that patch now ... will let you know
[14:58] <pitti> apw: do you have more of those cards which make boot faster?
[14:58] <apw> heheeh
[14:59] <apw> pitti, is there a bug for this 5s delay?
[14:59] <pitti> apw: yes, hang on
[14:59] <DktrKranz> mvo: so, do you plan to upload 0.6.0 soon?
[14:59] <pitti> apw: bug 510937
[14:59] <apw> pitti, excellent thanks, i'll get it on list
[14:59] <pitti> apw: (with some things which I tried, etc.)
[15:01] <mvo> DktrKranz: I think that would be a good thing, it would be nice to make sure the changelogs are all merged and no fixes get lost. I will not really have much time until feature freeze unfortunately :/
[15:02] <DktrKranz> oh :(
[15:02] <DktrKranz> I'll give it high prio
[15:02] <mvo> many thanks DktrKranz!
[15:02] <smoser> hm... persia just tested 'fsck device' of 400G disk with 1G usage (about what we have in our root images). it took .5 seconds.
[15:03] <persia> smoser: So maybe just leave it alone?
[15:03] <smoser> so it would seem that a forced interval check will cause first-boot delay of similar time
[15:03] <smoser> yeah
[15:03] <smoser> i think so
[15:03] <smoser> i was just thinking it would take as long as when my system reboots and decides to fsck the large /home
[15:16] <pitti> computer freezing during dist-upgrade, breaking futher boot -> priceless
[15:16] <sebner> heh
[15:16] <sebner> pitti: even in recovery mode?
[15:17] <pitti> no, just booted -12, dpkg --configure -a, done
[15:17] <Mirv> would anyone have something insightful to say to the usb-modeswitch thread I started on devel-discuss (https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-February/010647.html)? I'm wondering if it's something we'd really want but which just hasn't been on the radar.
[15:17] <pitti> I don't know what caused it to crash
[15:18] <cjwatson> Mirv: surely we just want the kernel to DTRT by default rather than going down the usb-modeswitch rat-hole; this is the upstream trend
[15:18] <cjwatson> Mirv: it already DTRT for quite a few devices, rendering usb-modeswitch unnecessary as well as its existing unreliable state :-)
[15:19] <cjwatson> Mirv: see e.g. linux/drivers/usb/storage/option_ms.c, the zerocd stuff
[15:19] <Mirv> cjwatson: ok, that's what I was thinking about but then again usb-modeswitch seems to continue to develop. maybe then the reason for its existence goes away soon(ish)
[15:19] <cjwatson> Mirv: personally, when I needed such a device to work, I found it *easier* to beat the kernel into shape than to wrestle with the various possible userspace nightmares
[15:20] <cjwatson> and I'm not a kernel hacker
[15:20] <cjwatson> the userspace stuff just plain didn't work for me
[15:20] <cjwatson> I'd be very concerned about advertising that it's the Way to get things to work, and thus undermining getting things fixed in the kernel
[15:21] <Mirv> I'm just thinking about the user space impact for lucid and if it's possible to evaluate it. But maybe it's indeed too hackish solution to be called a solution, no matter how it would help some.
[15:22] <cjwatson> I found that in some situations the presence of udev rules for this actually made things worse, because I ended up with races
[15:22] <Mirv> I was asking it mostly because I haven't bumped into the numerous problems described by some others, while in my case it was simply doesn't work at all / works fluently with usb-modeswitch.
[15:22] <cjwatson> in your position, I would try to get the kernel to switch the device to networking mode by default
[15:23] <cjwatson> which is probably just a matter of a quirk in the appropriate mass storage driver
[15:23] <Mirv> Well, anyway, may that thread rest in peace then.
[15:23] <Mirv> cjwatson: Ok, will put that to my todo list.
[15:23] <mvo> tkamppeter: I looked at the hplip thing again and I noticed that there is a com.hp.hplip dbus object already. I think its best to use that, maybe in cooperation with upstream and add a method to trigger the NeedPlugin signal. if the signal then is available from the app it should work. the reason it is currently not working is that there is no signal on the com.hp.hplip that is available on the bus registered
[15:23] <cjwatson> I agree that usb-modeswitch is often a way to get otherwise non-working hardware to work
[15:24] <cjwatson> I'm just not very convinced it's a real properly supportable option
[15:25] <cjwatson> but I'm just another user from this point of view, albeit one who ended up in quite a few discussions with various appropriate upstreams last time round :)
[15:25] <Mirv> ok :) well, there is still a little bit of time if someone has an undisputable perfect solution that makes all 3G modems work out-of-the-box.
[15:26] <Mirv> but otherwise let's just encourage people to fix the quirks in the kernel
[15:28] <cjwatson> Mirv: what's your pci id?
[15:31] <Mirv> cjwatson: usb id? it looks like 12d1:1446 before usb-modeswitch does the switch, after that 12d1:1001
[15:31] <cjwatson> err, right
[15:32] <cjwatson> Mirv: you might find it's as simple as http://paste.ubuntu.com/374035/ then
[15:33] <Mirv> cjwatson: heh, that was fast. I'll try that out and report later.
[15:33] <cjwatson> can't be sure, but the other huawei devices all seem to be handled basically the exact same way
[15:34] <mathiaz> jdstrand: mdeslaur: hi - where can I find the genshi templates used by the security team?
[15:37] <jdstrand> mathiaz: https://code.launchpad.net/~usn-tool/usn-tool/trunk
[15:40] <mathiaz> jdstrand: thanks - IIUC genshi doesn't support template inheritance?
[15:41] <jdstrand> mathiaz: hmm, not sure-- I didn't develop that code (I've only ever modified it slightly)
[15:42] <tkamppeter> mvo, can you tell me what I exactly need to change on HPLIP and where?
[15:43] <geser> mathiaz: no, genshi doesn't support inheritence but you can use includes (XInclude) to reuse templates
[15:43] <tkamppeter> mvo, I have your new update-notifier and my new hplip installed and it does not work.
[15:44] <mathiaz> geser: well - I'll write some text based templates (to generate preseed files)
[15:44] <mathiaz> geser: IIUC XInclude is only available for XML templates
[15:44] <geser> right
[15:45] <mvo> tkamppeter: yeah, the reason is that dbus-send is not the best way for doing this, it better to change the existiing com.hp.hplip provider. I have not digged into that code yet, but it should be striaghtforward. maybe upstream is interessted in helping? otherwise I can work on it after feature-freeze on fixing it up
[15:45] <geser> mathiaz: use "{% include ... %}" instead
[15:45] <geser> http://genshi.edgewall.org/wiki/Documentation/text-templates.html#snippet-reuse
[15:47] <tkamppeter> movo, we consider this feature as included now and work with time on it after feature freeze. Now I will make sure that all the other printing packages are up-to-date.
[15:47] <tkamppeter> mvo: ^^
[15:48] <mvo> tkamppeter: yeah, at this point it becomes a bugfix, if the hplip dbus stuff is done in python it should be pretty trivial
[15:48] <tkamppeter> mvo: After that I can talk with upstream to find a concept for the hp-plugin call via D-Bus.
[15:49] <mvo> tkamppeter: thanks, please talk to upstream first and if I have a spare minute I check the code
[15:49] <tkamppeter> mvo, this stuff is in fact done in Python.
[15:51] <tkamppeter> mvo, one thing is important: Before release we MUST have a way for hp-plugin to pop up when connecting such a printer, even if it is an interim solution and upstream provides something more streamlined after our release.
[15:52] <mvo> tkamppeter: if we run dbus-send without --dest and with --print-reply then we can patch update-notifier to get those events. its a bit ugly, I would prefer to have it part of the real interface at com.hp.hplip. but its a backup plan if everything else fails
[15:53] <tkamppeter> mvo, OK, so let us change the packages to this mode and change them again until we get a better solution.
[15:54] <tkamppeter> mvo, so I do only s/--dest/--print-reply/ on the dbus-send command line?
[15:55] <mvo> tkamppeter: I would prefer to investigate the better solution first, I can work on it later today
[15:55] <micahg> Ubuntu Mozillateam meeting in #ubuntu-meeting in 5 minutes
[15:56] <mvo> tkamppeter: the diff in update-notifier is really a bit ugly
[15:57] <tkamppeter> mvo, then please tell me as soon as you have found some way and tell me then what to change in HPLIP.
[15:57] <mvo> tkamppeter: I will
[16:03] <tkamppeter> mvo, note that it is possible (I did not verify) that the part of HPLIP which is listening for the com.hp.hplip is some Qt-based part which is not used by standard installations (the applet of HPLIP will only get started if hplip-gui is installed). Our concept must also work in GNOME-only environments as an Ubuntu or Edubuntu off-the-CD standard install.
[16:12] <sladen> Mirv: usb-modeswitch is a very long-winded way of sending a single usb-mass-storage command to the device's first profile
[16:15] <sladen> Mirv: grep -hr MessageContent usb_modeswitch.d/ | sort -n | uniq -c | sort -rn   shows the level of duplication in the configuration files
[16:16] <sladen> Mirv: I'm not even aware that the people that wrote it have *any idea* what binary crap they are poking to the device
[16:17] <sladen> Mirv: eg. the first four bytes of all of those are  "USBC"  which is that usb mass storage protocol header
[16:17] <sladen> Mirv: ...I do like that it is done in userspace though, as so easy to disable if you wanted something else
[16:18] <lucas> running with kernel 2.6.32 from debian sid on a debian lenny. chrooting to a lucid amd64 chroot works fine. chrooting to a lucid i386 segfaults. does it ring a bell?
[16:20] <slangasek> lucas: yes, because the Debian kernel team has said that kernel is broken
[16:21] <lucas> slangasek: ah, wasn't aware of that. breakage related to that specific problem?
[16:21] <slangasek> related to running 32-bit userspace on a 64-bit kernel, yes
[16:21] <lucas> ok
[16:21] <lucas> thanks
[16:21] <slangasek> it appears the fix is in NEW
[16:24] <lucas> ah yes it's known as #568416
[16:28] <Laibsch> Keybuk: I'm currently working with Ahmed to get sl-modem out of its broken state and back into usable shape for lucid.  First step is to push back all the changes that Ubuntu did so we can sync from Debian again.
[16:29] <Laibsch> Most of them are done.  sl-modem (2.9.11~20080817-3ubuntu2) changes are partially done.
[16:30] <Laibsch> Neither Ahmed nor I are kernel or udev hackers.  Would you be willing to inspect the package before we upload to Debian to make sure that indeed the package to be uploaded to Debian has made the current Ubuntu delta obsolete?
[16:30] <Keybuk> sure, I'll read through the diff
[16:30] <Laibsch> We may have a question or two along the way as well and it would be great if you could mentor us here or there.
[16:30] <Laibsch> Keybuk: debdiff?
[16:31] <Keybuk> well, either really
[16:31] <Laibsch> upstream version has changed and Ahmed made a lot of other changes as well.  I'm not sure reading the debdiff will be doable.
[16:31] <Keybuk> ok, well, send me whatever you want me to look at
[16:31] <Laibsch> cool
[16:31] <Laibsch> thanks
[16:33] <alkisg> From /etc/init/gdm.conf: [ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/gdm" ] || { stop; exit 0; }
[16:33] <alkisg> Shouldn't that be '!=' instead of '='    ? Or am I reading this wrong?
[16:33] <alkisg> (my problem is that failsafeXinit runs even though I have ldm as the default-display-manager)
[16:34] <ev> mvo: are you okay with ubiquity-slideshow-ubuntu-upgrade, built out of ubiquity-slideshow-ubuntu, as the source for the upgrade slideshow, per Dylan's email?
[16:34] <Keybuk> alkisg: no, it should be =
[16:35] <Keybuk> alkisg: read it as "there's no default-display-manager file, or the file says gdm, OR don't use gdm"
[16:35] <Keybuk> ie. gdm won't start if there's a default-display-manager file that doesn't say gdm
[16:36] <alkisg> Keybuk: thanks, that final || got me confused :)  Any ideas on why failsafe runs even though  I don't use gdm (but have it installed) ?
[16:36] <Keybuk> alkisg: no idea on that
[16:36] <alkisg> Thank you though :)
[16:42] <\sh> Keybuk: what about SRU the ifupdown fix for upstart for "virtual" network devices like bonds/bridges/etc?
[16:43] <\sh> Keybuk: for karmic that is:)
[16:45] <dpm> hey kirkland, you've already got the first 4 new testdrive translations after the announcement :) -> https://translations.edge.launchpad.net/testdrive
[16:51] <Keybuk> \sh: I know nothing about it?
[16:58] <rickspencer3> ug
[16:58] <rickspencer3> I just realized that our trendline for A3 points to the 24th instead of the 18th :(
[16:58] <rickspencer3> we are way over
[16:58]  * rickspencer3 cries
[16:58] <Keybuk> rickspencer3: problem with the burnout charts?
[16:59] <rickspencer3> oops
[16:59] <rickspencer3> wrong burndown chart
[16:59] <rickspencer3> I was looking at Dx
[16:59] <rickspencer3> Keybuk, well, I think we should consider the 18th the cut off point for working on A3
[16:59] <rickspencer3> that's the Thur before we release A3
[16:59] <rickspencer3> right?
[17:00] <Keybuk> alphas are a lot loser than beta
[17:00] <Keybuk> really the tuesday before
[17:00] <rickspencer3> yeah
[17:00] <rickspencer3> ok
[17:00] <Keybuk> but things sneak in overnight
[17:00] <Keybuk> so the 23rd
[17:00]  * sebner waves at rickspencer3 :)
[17:00] <rickspencer3> Keybuk, how's it going? good trip back?
[17:00]  * rickspencer3 waves to sebner
[17:01] <Keybuk> rickspencer3: not too bad, slept for most of the flight
[17:01] <Keybuk> and don't seem to be suffering too much for jet lag
[17:01] <rickspencer3> nice
[17:01] <Keybuk> and I now only have 1,700 mails left to read
[17:01] <Keybuk> *cry*
[17:02] <rickspencer3> Keybuk:
[17:02] <rickspencer3> cntrl-A, Delete
[17:02] <rickspencer3> spam a mail ...
[17:02] <rickspencer3> oops, I lost my inbox
[17:02] <rickspencer3> if you sent me something important in the last two weeks, please resend
[17:02] <Keybuk> rickspencer3: sadly these are the important ones I have to actually deal with
[17:02] <rickspencer3> you will get like 2 emails back
[17:06] <\sh> Keybuk: the workaround^Wfix for bug #446031
[17:07] <Laibsch> Keybuk: the current Ubuntu delta is http://git.debian.org/?p=collab-maint/sl-modem.git;a=commitdiff;h=1a5b58d3f49902e7c9e6f85c4acee22d07550c1a
[17:08] <Laibsch> we looked carefully through it and have pushed back where appropriate
[17:08] <Laibsch> there is one remaining difference
[17:08] <Keybuk> \sh: nothing to do with me
[17:09] <Keybuk> \sh: I'm not planning an SRU
[17:09] <Keybuk> in general, I don't do them
[17:09] <Laibsch> debian/sl-modem-daemon.modutils which is installed as /etc/modprobe.d/sl-modem.conf: http://git.debian.org/?p=collab-maint/sl-modem.git;a=blob;f=debian/sl-modem-daemon.sl-modem.modprobe;h=01db2ad8f27d427fdf8f7d4a45970a3568082c62;hb=HEAD
[17:10] <Laibsch> My feeling is that, actually it was these udev changes that broke sl-modem for me (and everybody else I know)
[17:10] <Keybuk> Laibsch: looks right
[17:10] <Keybuk> which udev changes?
[17:11] <Laibsch> the stuff you changed in 2.9.11~20080817-3ubuntu2 because udev should "just do it"
[17:11] <Keybuk> right
[17:11] <Laibsch> http://git.debian.org/?p=collab-maint/sl-modem.git;a=commitdiff;h=1a5b58d3f49902e7c9e6f85c4acee22d07550c1a
[17:11] <Keybuk> that fixed the module loading
[17:11] <Keybuk> before that it wouldn't be loaded by anything
[17:11] <Laibsch> apparently not
[17:12] <Laibsch> but it may be something else
[17:12] <Laibsch> Keybuk: do you have an sl-modem in some of your devices?
[17:12] <Keybuk> and calling mknod from a modprobe script is just *wrong*
[17:12] <Keybuk> Laibsch: nope
[17:12] <Laibsch> :-(
[17:12] <Laibsch> OK
[17:12] <Laibsch> sl-modem doesn't really do anything at least since Jaunty for me
[17:13] <Laibsch> the necessary devices are not created
[17:13] <Keybuk> probably a bug in the kernel code
[17:13] <Laibsch> But Jaunty was ubuntu2
[17:13] <Keybuk> it's an out-of-tree driver
[17:13] <Keybuk> so it's no surprise it's broken
[17:13] <Keybuk> jaunty's kernel dropped support for a bunch of old-style ways of doing device nodes
[17:14] <Laibsch> bug 375148
[17:14] <Keybuk> the driver probably needs updating
[17:14] <Keybuk> sure, so patch the driver to register it properly
[17:14] <Laibsch> OK
[17:14] <cjwatson> bryceh: I have a horrible feeling that I'm going to have to reimplement bullet-proof-X for my current project
[17:14] <Laibsch> that's where we'd hope for some help from you
[17:14] <Laibsch> Keybuk: Ahmed nor I are kernel-savvy
[17:14] <Keybuk> Laibsch: I really don't have the time to do that
[17:15] <cjwatson> bryceh: the reason is that the process structure of failsafeXServer is such that ubiquity-dm isn't going to get the required SIGUSR1 if it just calls failsafeXServer
[17:15] <Laibsch> Keybuk: where is the place to look?
[17:15] <Keybuk> Laibsch: the module init is a good place to start
[17:15] <Keybuk> compare with an in-kernel driver
[17:16] <Keybuk> though I have a sudden feeling that you may be hitting a gregkhism
[17:16] <Keybuk> and that out-of-kernel drivers aren't allowed to have device nodes anymore
[17:16] <Laibsch> which is?
[17:16] <cjwatson> bryceh: besides, the calling convention isn't really ideal for me anyway.  Do you think it might be possible to split out the driver selection and xorg.conf.failsafe writing so that I don't have to duplicate it?
[17:16] <Keybuk> well, non-GPL drivers
[17:16] <\sh> Keybuk: your expertise regarding upstart, do you think it's sane to do an SRU with the fix in ifupdown?
[17:16] <Keybuk> \sh: no
[17:16] <cjwatson> bryceh: (or has kdm already done some of this?  I haven't looked at its bullet-proof-X implementation, if any)
[17:17] <Laibsch> Keybuk: thanks.  I'll talk to the kernel guys to see if they confirm this (and possibly have a fix)
[17:18] <Keybuk> Laibsch: no problem
[17:18] <Keybuk> Laibsch: basically the way it's supposed to work is the module registers a chardev major or minor
[17:18] <Keybuk> Laibsch: and that results in the uevent going out and udev making the device node
[17:18] <Keybuk> a simple ttyUSB module should show the right code sequence
[17:18] <Laibsch> sounds challenging
[17:18] <Keybuk> it's really easy
[17:18] <Laibsch> OK
[17:19]  * Laibsch hopes for more of this mentoring
[17:19] <Laibsch> I'm off to see what I can get from the information provided
[17:20] <nailora> zim is a great desktop wiki, that recently switched to python (formerly perl). updated packages are in debian testing ( http://packages.debian.org/squeeze/zim ) but not yet in ubuntu. is there a chance it can be included in lucid?
[17:21] <Keybuk> Laibsch: I think it's as simple as calling register_chrdev_*()
[17:21] <bryceh> cjwatson, kdm hasn't done it afaik, but yes, splitting this out is definitely doable - in fact I just wrote up a blueprint yesterday for moving failsafex out of xorg
[17:22] <bryceh> cjwatson, however there really isn't "driver selection logic" - it just picks vesa and pastes an xorg.conf into place.
[17:22] <cjwatson> bryceh: there's a little bit for powerpc and the like :)
[17:22] <bryceh> cjwatson, it used to be more sophisticated, but these days thats all we've needed
[17:22] <cjwatson> bryceh: do you think it's a "by feature freeze" kind of thing, or should I just go ahead and hack something into ubiquity now which we can refactor later?
[17:23] <cjwatson> if you don't think it'll change all that much, that might not be a big problem
[17:23] <bryceh> cjwatson, what I'm working on is a lucid+1 type thing
[17:23] <cjwatson> right, I'll hack something up for now and send you a reference then?
[17:23] <bryceh> so I'd suggest the ubiquity hacking approach
[17:23] <bryceh> sounds good
[17:24] <Laibsch> nailora: open a ticket in Launchpad.  Google for DebianImportFreeze which is looming, you have little time.
[17:24] <cjwatson> the next question is how the hell to test this, of course
[17:24] <cjwatson> nailora: when did they hit squeeze?
[17:24] <cjwatson> must have been recently, I synced in most of the new packages yesterday
[17:24] <cjwatson>        zim |     0.43-1 | lucid/universe | source
[17:25] <cjwatson> it failed to build: http://launchpadlibrarian.net/38664080/buildlog_ubuntu-lucid-i386.zim_0.43-1_FAILEDTOBUILD.txt.gz
[17:25] <cjwatson> looks like a debian vs. ubuntu python thing
[17:26] <cjwatson> I can probably fix that up
[17:28] <nailora> cjwatson: i would appreciate that a lot!
[17:28] <nailora> Laibsch: thanks for your hint
[17:28] <cjwatson> running build
[17:28] <cjwatson> Enter passphrase for key '/home/cjwatson/.ssh/id_rsa':
[17:28] <cjwatson> What. The. Heck.
[17:28] <cjwatson> nailora: you can skip Laibsch's comment though, doesn't need a bug
[17:28] <cjwatson> it would have needed a bug if it hadn't actually been synced already
[17:29] <Keybuk> cjwatson: damn, I've already harvested over a dozen passphrases that way
[17:30] <nailora> cjwatson: i did not / do not file a bug while you are looking at it / working on it. just wanted to thank him that he bothered to reply.
[17:30]  * cjwatson nods
[17:30] <nailora> and i have absolutely no idea about why it asks for an ssh key
[17:32] <cjwatson> it's under 'bzr version-info --format python', but that shouldn't normally need to connect to anything
[17:32] <cjwatson> I could just use the source package, I suppose, but ...
[17:33] <cjwatson> must be because it's a checkout.  urgh.
[17:33] <cjwatson> yeah, all better if I unbind.
[17:37] <bdrung> cjwatson: you did some uploads of ntfs-3g. can you merge the newest version from Debian (bug #513197)?
[17:38] <cjwatson> bdrung: ok
[17:39] <bdrung> cjohnston: thanks
[17:39] <\sh> c/quit
[17:39] <\sh> argl
[17:42] <persia> \sh: you're stuck here, and can never leave :)
[17:42]  * ogra humms hotel california
[17:43] <cjwatson> xnox: err, why are you sending linkedin invitations to Launchpad merge proposals?
[17:43] <xnox> cjwatson: LinkedId did it for me
[17:43] <xnox> I'm very sorry
[17:43] <ogra> cjwatson, business reasons :)
[17:43] <cjwatson> !
[17:43] <xnox> I use gmail and it imported
[17:44] <cjwatson> surely it's within your control which addresses you use
[17:44] <xnox> all the emails
[17:44] <cjwatson> ok, please please be more careful in future
[17:44] <xnox> I will I'm sorry
[17:44] <cjwatson> maybe there should be a more free-software-friendly equivalent of linkedin ;-)
[17:45] <xnox> yeah. And maybe spam filters should catch invintations to facebook / linkedin and all those things
[17:45] <xnox> I've dented & tweeted & blogged about the incident now
[17:45] <ogra> sadly they dont ... i seem the invites regulary
[17:45] <xnox> Again sorry =(
[17:45] <ogra> on MLs i'm on
[17:46] <nailora> cjwatson: i am not exactly sure if you succeeded, but thank you for having a look at it on all accounts
[17:46] <ogra> which usually creates a flamewar
[17:47] <cjwatson> xnox: ah, didn't see the blog entry, sorry for the duplication then
[17:47] <cjwatson> nailora: nearly done
[17:47] <xnox> cjwatson: well I've hit the publish button a few seconds after your ping on irc ;-)
[17:48] <cjwatson> nailora: actually, you know what, it's fixed in unstable, I'll just sync it
[17:49] <cjwatson> needs a new debhelper so I'll have to merge that
[17:49] <sebner> rickspencer3: any idea whom I wan to contact about questions regarding the canonical store?
[17:50] <sebner> *want
[17:50] <rickspencer3> sebner, is there not contact information on the web page?
[17:51] <rickspencer3> tbh, I have no idea
[17:51] <sebner> rickspencer3: there is (I'm trying to help one in the german ubuntu support forum) but no reply in months.
[17:51] <sebner> nvm then
[17:51] <rickspencer3> sebner, that sux
[17:52] <rickspencer3> this channel is prolly not a great place to get support for that though
[17:52] <rickspencer3> perhaps #ubuntu?
[17:52] <sebner> rickspencer3: sure, therefore I was highlighting you ^^
[18:00] <bluefoxicy> we should make more things jiggly
[18:00] <bluefoxicy> menus should jiggle when they drop
[18:00] <bluefoxicy> resizing a window should stretch it, like it's rubber, following and then snapping to its new size
[18:02] <persia> Please no.
[18:02]  * bluefoxicy takes that sentence structure away
[18:02] <bluefoxicy> "we should have more jiggly things" <--> "you should make things more jiggly"
[18:03] <persia> That's even less exciting :)
[18:03] <Keybuk> things should not jiggle
[18:03] <Keybuk> that's why the jockstrap and the bra were invented
[18:03] <bluefoxicy> persia:  the "enhanced" graphics thing that adds "more pleasing visual effects" seems to only make the windows jiggly when you move them
[18:03] <bluefoxicy> that's all it does
[18:03] <bluefoxicy> windows now jiggle when they're dragged
[18:03] <persia> Not mine, but I take care to keep my environment pleasing by uninstalling stuff that claims to make it "better" :)
[18:06] <bluefoxicy> i just think the modes shouldn't be "non-accelerated" vs "Composited" vs "Composited, and windows jiggle when dragged"
[18:06] <bluefoxicy> if I want jiggly windows, it's probably even better to have a fully action-oriented desktop
[18:07] <bluefoxicy> windows appear by being explosively thrown on the screen (see original Gnome Wobbly Windows demo); minimized windows squish and flow into the taskbar buttons; menus slide and stretch and wobble into place as they drop
[18:07] <bluefoxicy> if I don't want all that stuff, it's likely I don't want my windows to jiggle like jello jigglers either
[18:08] <Keybuk> bluefoxicy: and if you move a window too fast, it could burst into flames
[18:08] <bluefoxicy> xD
[18:11] <persia> bluefoxicy: I'm in complete agreement with that: if you want wiggly bits, you should have *lots* of them.
[18:12] <bluefoxicy> yeah it just makes sense
[18:19] <jono> seb128, do you know offhand if the IMAP speed-up features in Evolution are in Lucid?
[18:19] <jono> I am considering moving back from TB
[18:22] <micahg> jono: hopefully TB3 will hit Lucid this weekend if it helps any
[18:23] <jono> micahg, cool! I am running it our of their upstream release right now
[18:23] <jono> the search is just so slow though
[18:23] <jono> the whole new tab and search view feature
[18:23] <snap-l> Does Evolution have any plans of using a better HTML rendering engine?
[18:23] <micahg> jono: you can change the search with teh drop down back to the old style
[18:23] <snap-l> Tht's been the real deal-breaker for me with Evo. That and threading
[18:24] <kees> mdeslaur: btw, new virt-manager rocks.  :)
[18:26] <mvo> ev: ubiquity-slideshow-ubuntu-upgrade> yes
[18:57] <ev> mvo: awesome, I'll upload that tonight then
[18:57] <mvo> ev: very nice
[19:31] <bdrung> Keybuk: you are the maintainer of mountall. i wanted to run mountall with --debug (for providing more information to bug #507613) and write it into a file, but when mountall is launched, there is no writeable file system. do you have an idea how to get the debug information?
[19:32] <Keybuk> bdrung: write it to a tmpfs ?
[19:32] <Keybuk> like /dev
[19:33] <bdrung> Keybuk: and how can i save the file to survive the reboot?
[19:49] <Keybuk> bdrung: remount the filesystem r/w and copy it over?
[19:50] <bdrung> Keybuk: the system will hang. so i cannot type commands into the terminal
[19:56] <tlyu> does the launchpad bug watch updater only run periodically? i updated a debian bug that is linked in launchpad; should i expect the change to propagate?
[19:58] <arand> tlyu: yea, I think daily at least, definitely not instant.
[19:58] <bdrung> tlyu: yes, it's run periodically (or there is a other reason for the delay).
[19:58] <tlyu> ok, thanks
[19:59] <bdrung> tlyu: we had a bug that prevents the update, but this bug is already fixed.
[20:25] <ari-tczew> any sponsor for main got a minute?
[20:28] <frafu> Hi, could anybody please tell me whether it is normal that python-distutils-extra and DistUtilsExtra.auto have two different version numbers?
[20:34] <frafu> Hi pitti; could you have a look at LP: #520548 ? Thanks.
[20:35] <frafu> https://bugs.launchpad.net/ubuntu/+source/python-distutils-extra/+bug/520548
[20:41] <bdrung> slangasek: hi. You did many uploads of hdparm. can you merge version 9.27-2 from Debian (bug #516249)?
[20:55] <DktrKranz> mvo: Debian gdebi branch with common ancestor from LP ready
[20:56] <mvo> sweet, many thanks DktrKranz
[20:56] <lamalex> Is there a way to install debs to an alternate location for testing?
[20:56] <DktrKranz> mvo: thanks for letting me know, it's definitely more manageable now! :)
[20:56] <lamalex> I'm working on some modifications to dpkg I need to test- but I'm understandably weary about replacing my system's dpkg :P
[20:56] <mvo> :)
[20:56] <mvo> DktrKranz: cool, I hope it was not too much fiddling around
[20:57] <lamalex> mvo: I think you're probably who I want to talk ask specifically :)
[20:57] <DktrKranz> (right now there are 6 conflicts, but nothing troublesome)
[20:57] <lamalex> s/talk//
[20:57] <mvo> lamalex: cjwatson is our best dpkg expert currently I think, but I may be able to help as well
[20:57] <lamalex> mvo: you at least know about hacking on parts of your system you dont want to break
[20:58] <mvo> haha - oh yes
[20:58] <lamalex> :)
[20:58] <mvo> chroot and kvm FTW!
[20:58] <lamalex> yeah, I was hoping there was an easier way. some dpkg flag. but I guess when I'm installing dpkg, if I break dpkg, a dpkg flag won't help me haha
[20:59] <lifeless> or lvm snapshots
[20:59] <lifeless> but they are pretty crude
[20:59] <lifeless> +1 on kvm (or uec even :))
[20:59] <lamalex> and I dont think I have lvm on this machine anyway
[21:00] <mvo> lamalex: well, it depends on what bits you are working on, a copy of the status file is certainly a good idea :) what changes are you making?
[21:00] <lamalex> mvo: I emailed you a while ago about dynamic dependencies
[21:00] <lamalex> we decided to do it at the dpkg level
[21:00] <mvo> lamalex: ohh, right. I remember that mail. didn't I reply? I think I did
[21:01] <lamalex> you did
[21:44] <bigon> could someone have a look at papyon merge? the new version is really needed in ubuntu
[21:45] <seb128> jono, I doubt it, we stay on 2.28 which is the karmic version...
[22:00] <mvo> DktrKranz: I merged the debian branch now into trunk, I think we are there for a unified version :) if you could double check, that is most appreciated
[22:07] <DktrKranz> mvo: looking
[22:19] <persia> Could an archive-admin take a look at the swt-gtk binary NEW?  The new packages are handovers from eclipse, which has already been uploaded to not build them anymore.
[22:20] <DktrKranz> mvo: sounds good, your soultion for ubuntu-specific patches is great
[22:30] <Caesar> I thought the outcome at UDS was for the Sun Java packages to move to the partner repository?
[22:35] <persia> Caesar: swt-gtk isn't Sun Java.  VM vs. libraries.
[22:35] <Caesar> parse fail
[22:36] <persia> Caesar: I had the impression the UDS discussion was just about the sun-java6 package.
[22:36] <Caesar> Yes, that's what I'm asking about
[22:36] <persia> heh.  Gets confusing sometimes.  But other stuff, like swt-gtk, netbeans, etc. should just be in the regular repo.
[22:36] <Caesar> There's no sun-java6 to be found anywhere
[22:36] <persia> Hurrah!
[22:36] <Caesar> No, not really
[22:36] <persia> Why?
[22:37] <Caesar> I was expecting to be able to find it in the partner repo
[22:37] <Caesar> We have business requirements for it
[22:37] <Caesar> Or so our Java people tell me
[22:37] <persia> Aside from about 3 API calls and some function renames, we're mostly good with OpenJDK, and OpenJDK has lots of bugfixes (even from Sun) that sun-java6 still doesn't have fixed.
[22:38] <Caesar> The Android SDK explicitly says it wants Sun Java, last time I looked
[22:38] <Caesar> and I once tried to use it with OpenJDK and it broke in weird and wonderful ways
[22:38] <Caesar> Where once is ~ 6 months ago
[22:38] <persia> Ugh.  Yeah, unfortunately there is still some stuff that needs porting work to deal with distributed libraries.  Nothing like the volume that will be required with Java 7, but without code, some stuff can't yet run on OpenJDK (and even with code, some stuff is obnoxious to port)
[22:39] <soren> Hm... Firefox has forgotton about all my search engines except Ask.com.
[22:41] <[reed]> soren: iirc, that's because of the way ubuntu does the packaging
[22:41] <soren> I can't help but notice that the search plugin things in the firefox package are kept in a directory called en-US, so perhaps they're limited to that locale?
[22:44] <soren> Guess not..
[22:44] <soren> set default searchplugin locale pref to en-US - which is used as a fallback if no matching searchplugins/LOCALE directory exists for the current locale directory
[22:44] <soren> from firefox' changelog.
[22:48] <micahg> soren: we're working on localized plugins
[22:54] <soren> micahg: ..but until then, anyone not on en-US is without search plugins?
[22:57] <soren> micahg: Oh, found the problem. Yay.
[22:58] <micahg> soren: great, what was it?
[22:58] <soren> micahg: /usr/lib/firefox-addons/searchplugins was a symlink to '.' rather than en-US.
[22:59] <micahg> soren: is that in the package or you mad that?
[22:59] <soren> Oh, sorry, I meant /usr/lib/firefox-addons/searchplugins/common
[22:59] <soren> In the package, I suspect. I certainly didn't make it so.
[22:59] <soren> https://bugs.edge.launchpad.net/ubuntu/+source/firefox/+bug/520682
[23:00]  * micahg is looking at teh packaging now
[23:00] <soren> micahg: Lovely, thanks.
[23:01] <soren> grep search debian/firefox.links
[23:01] <soren> /usr/lib/firefox-addons/searchplugins /usr/lib/firefox-addons/searchplugins/common
[23:01] <soren> micahg: ^^ There's our problem.
[23:02] <micahg> hmm
[23:02] <soren> That should read "/usr/lib/firefox-addons/searchplugins/en-US /usr/lib/firefox-addons/searchplugins/common"
[23:02] <micahg> soren: I don't know if we want to do that...but I'll check...I think we're shooting for localized plugins this time around
[23:03] <micahg> asac: ^^
[23:34] <seb128> siretart, siretart_: hi
[23:35] <seb128> siretart, siretart_: thanks for your seahorse change, when you do upload something maintained in bzr could you update bzr too though?
[23:35] <seb128> siretart, siretart_: or ping somebody to sponsor your change if you don't want to do that
[23:41] <StevenK> seb128: I've accepted launchpad-integration, I'm going to do a no-change upload for tomboy and gbrainy so they link against the right binary package
[23:42] <seb128> StevenK, ok thanks