[00:05] <superm1> and cjwatson had a commit for the fix to bug 524169  on the tree ready to go too
[00:07] <slangasek> superm1: ok, that sounds like a set worth uploading then
[00:07] <slangasek> superm1: please go ahead
[00:07] <superm1> alrighty, thanks
[00:10] <Sarvatt> so something is sending a quit signal to x's controlling tty when some people press enter after first boot ( http://paste.ubuntu.com/382615/ shows it coming from the tty layer) when plymouth is used. suse seems to be getting around it with http://suse-moblin.com/obs-status/Moblin:Factory/aaa_base/aaa_base-bootsplash.patch anyone familiar enough with plymouth to dig into it more? i noticed one place where it could be resetting the ISIG flag o
[00:10] <Sarvatt> n plymouths tty (in src/libplybootsplash/ply-terminal.c) so the enter key (0x1c) becomes Control-\ (0x1c) if the same VT is used for X but its a bit over my head.
[00:23] <slangasek> pitti, bryceh: what's the status of hal removal now?  I see it included on daily desktop ISOs, which seems to put the lie to what was written in the A2 tech overview :)
[00:23] <bryceh> slangasek, afaik we no longer use it for anything
[00:24] <bryceh> slangasek, so if you spot something X-ish which does, let me know as it's a bug
[00:24] <slangasek> it's in main because of libvirt-bin, but that doesn't explain it being on the CD; will dig
[00:25] <slangasek> ah, it's pitivi
[00:25] <ccheney> lol
[00:25] <bryceh> heh
[00:25] <slangasek> seb128, robert_ancell: does pitivi need this Recommends: hal?
[00:26] <robert_ancell> slangasek, not sure, seb128 do you know?
[00:26] <robert_ancell> slangasek, thanks for your help with plymouth+upstart.  It's driving me insane :)
[00:26] <seb128> slangasek, yes
[00:26] <slangasek> seb128: waah - why? :)
[00:26] <seb128> slangasek, it needs to be ported to python-gudev
[00:26] <slangasek> robert_ancell: is it /still/ driving you insane? :/
[00:27] <seb128> slangasek, because it uses it...
[00:27] <robert_ancell> slangasek, yeah.  I already knew about the /proc issue (I've tried mounting it before running plymouthd and modifying plymouthd to not require it)
[00:27] <slangasek> seb128: is that likely to happen in lucid?  I guess the daemon is no longer started by default so it's not a huge problem, right?
[00:27] <robert_ancell> slangasek, the problem I find is it's really hard to tell why it doesn't boot up
[00:27] <seb128> slangasek, https://bugzilla.gnome.org/show_bug.cgi?id=605920
[00:28] <slangasek> robert_ancell: even after fixing plymouthd to not mind if /proc is missing?
[00:28] <seb128> slangasek, would be nice for lucid, and correct for the start
[00:28] <robert_ancell> slangasek, yeah, did that ages ago.
[00:28] <robert_ancell> seb128, is gudev an official GNOME dependency?
[00:28] <slangasek> robert_ancell: mmk; is there some way I can get my hands on a running environment of what you're working on, to poke at directly?
[00:28] <seb128> robert_ancell, yes, there was no python bindings though
[00:28] <slangasek> (not that I'll have time until Friday, but)
[00:29] <seb128> robert_ancell, pitti get that solved now
[00:29] <robert_ancell> seb128, that's what I was going to ask pitti - is the halsectomy an ubuntu goal and/or a GNOME goal?
[00:29] <seb128> both I guess
[00:30] <seb128> not an official GNOME goal that I know
[00:30] <seb128> but they work toward deprecating it too
[00:30] <slangasek> bryceh: is this note about not having wacom support obsolete in a3?  I see xserver-xorg-input-wacom is in now
[00:30] <bryceh> slangasek, that's correct, wacom is good to go
[00:30] <slangasek> \o/
[00:33] <Sarvatt> well usb wacom support at least, serial digitizers still need an xserver change thats in git
[00:34] <Kai_> why is there a distribution upgrade available? I'm running lucid alpha 2.
[00:35] <persia> Kai_: Probably as part of the testing for the upcoming Alpha-3: you might get a more detailed answer in #ubuntu+1
[00:35] <Sarvatt> next xserver upload will have it, most tablet pc's need that
[00:35] <Kai_> okay, thanks
[00:52] <ccheney> is there a known issue with lucid that when you do autologin it doesn't seem to change to the X server
[00:53] <ccheney> i see the xcursor but not the rest of X
[00:54] <ccheney> 16.5s boot from upgraded lucid (not clean install by any stretch) not bad at all :)
[00:54] <ccheney> it just doesn't show X properly for some reason :-\
[01:04] <ccheney> hmm it worked after trying again
[01:04] <ccheney> seems to not be completely stable for me for some reason
[01:09] <slangasek> mdeslaur, zul: where did /etc/network/if-up.d/samba go in samba 2:3.4.5~dfsg-2ubuntu1 ?  this should have been kept until the conversion to upstart could be done (bug #526659)
[01:09] <slangasek> ccheney: bug #521175; would love it if you could figure out *why* autologin is different
[01:09] <mdeslaur> slangasek: looking now
[01:11] <slangasek> mdeslaur: if it's broken anyway, I'm inclined to just upload for bug #523868, I'm just surprised to see this regression
[01:11] <ccheney> slangasek: it didn't actually freeze for me, some of the times the xcursor showed up but not the rest of the desktop, other times it came up all the way but then x would crash after a short time, but would respawn ok
[01:11] <ccheney> on intel x4500
[01:12] <slangasek> ccheney: all the same thing.  Does gdm come up ok when *not* using autologin?
[01:12] <ccheney> slangasek: yea
[01:13] <ccheney> slangasek: and even when x didn't come up all the way i could still switch vt's
[01:13] <slangasek> ccheney: yep.  So somewhere in the gdm logic to interface with plymouth, there's a bug when autologin is used; but I couldn't find it when I tried to trace the gdm code
[01:13] <smoser> can someone accept nomination for lucid for https://bugs.launchpad.net/ubuntu/+source/euca2ools/+bug/526697
[01:13] <ccheney> oh ok
[01:14] <ccheney> on the times i booted up and xcursor was all that showed it played the login music with just the black screen, one time i switched vt's and the desktop showed up, iirc it crashed soon afterward though
[01:14] <ccheney> so maybe some kind of bug with the vt switching in plymouth/gdm, but not really sure
[01:19] <Sarvatt> every time that's happened to me ureadahead was reprofiling, could just be a coincidence though.
[01:20] <slangasek> there very definitely seems to be something different in gdm's interaction with plymouth when using autologin
[01:21] <slangasek> if someone can figure out what, that's probably the bug
[01:21] <slangasek> (and knowing what it is might help me fix other plymouth bugs, fwiw)
[01:26] <mdeslaur> slangasek: looks like the samba in lucid never got the if-up.d file added to debian/samba.files
[01:26] <mdeslaur> zul: ^
[01:27] <slangasek> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/462169/comments/64
[01:28] <zul> mdeslaur: i remember putting it in lucid its in lucid-updates as well
[01:28] <mdeslaur> zul: you forgot to add it to debian/samba.files
[01:28] <mdeslaur> zul: http://launchpadlibrarian.net/38098612/samba_2%3A3.4.3-2ubuntu1_2%3A3.4.3-2ubuntu2.diff.gz
[01:28] <zul> frig...
[01:28] <zul> my bad
[01:29] <slangasek> huh, ok :)
[01:29]  * mdeslaur votes for the upstart job :)
[01:29] <zul> as do i :)
[01:45] <homebrewcider> anybody use dvbcut? i get an error message saying "the chosen file *** contaqins no video"    anybody come across the before?
[01:46] <micahg> !support | homebrewcider
[01:47] <homebrewcider> oops sorry
[01:47] <homebrewcider> clicked the wrong room
[01:47] <persia> happens to everyone once :)
[02:55] <ScottK> Some much more frequently than that.
[03:40] <mohaa> o/
[03:40] <mohaa>   /usr/lib/claws-mail/plugins/notification_plugin.so: undefined symbol: menu_create_items
[03:40] <mohaa> i'm having issues with 2 plugins in claws-mail
[03:41] <mohaa> notification and att_remover
[03:41] <mohaa> is that here that i should adress  or to maintainer ?
[03:53] <jdong> mohaa: best to file a bug on launchpa
[03:53] <jdong> d
[03:53] <jdong> ubuntu-bug claws-mail
[03:54] <mohaa> doing it
[03:54] <mohaa> likely, it's too complicated :D
[03:54] <jdong> awesome, thank you.
[03:54]  * mohaa mad at maintainers not using their builds  :P
[03:55] <jdong> we're not being mean and trying to send you to the proverbial RT, just the bug tracker is the best way of getting the attention of those who care, so to speak.
[03:55] <mohaa> actually in this case CLAWS-MAIL has been upgraded  and not the plugins   -_-
[03:56] <mohaa> so we have fresh client  and plugins compiled for an older version of claws :-\
[03:56] <jdong> is this on karmic or lucid?
[03:56] <mohaa> :o
[03:56] <mohaa> 9.04
[03:56] <jdong> groan... yikes.
[03:57] <mohaa> i don't use this system much so....
[03:57] <jdong> ugh *rant mode* plugin packagers should properly depend on the version of the parent program they need....
[03:57] <mohaa> :D
[03:57] <jdong> *end rant* :)
[03:57] <ScottK> IIRC the one Ubuntu dev I know of that uses claws mail wasn't that active during Jaunty development.
[03:57] <ScottK> jdong: It probably just needs a rebuild.
[03:57] <mohaa> i see it
[03:57] <jdong> why am I getting a deja vu moment.
[03:57] <mohaa> it's still on 3.6 series  :-\
[03:58]  * ScottK used to need to care about claws when it has clamav plugin.
[03:58] <mohaa> ScottK_san it still has it  ;)
[03:59] <nigelb> mohaa: you probably could check this ppa https://launchpad.net/~claws-mail/+archive/ppa
[03:59] <mohaa> nigelb  thx :)
[04:00] <mohaa> i'm using a quite old buntu so...
[04:02] <syn-ack> hey, didnt Alpha 3 drop today?
[04:03] <bryceh> Thursday
[04:03] <syn-ack> I could have sworn the timeline said today
[04:04] <bryceh> February 25th
[04:04] <syn-ack> Must have confused it with the rebuild test
[04:04] <jdong> I think a 3-day pushback.
[04:04] <syn-ack> Ok, so I'm NOT nuts
[04:04] <jdong> just got the freeze announcement this morning
[04:04] <jdong> which mentioned a schedule delay :)
[04:05] <jdong> so no, you probably correctly marked your calendar
[04:08] <mohaa> jdong: https://bugs.launchpad.net/ubuntu/+source/claws-mail/+bug/526831   ;)
[04:15] <ScottK> jdong: Milestone releases are always on Thursdays.
[04:15] <jdong> ah, gotcha
[04:16] <ScottK> Freeze on Tuesday and release on Thursdays for Alphas.
[04:59] <nasserash> hello everyone: I'm trying to compile with gcc a program and I need the -lsocket library, I installed "happycoders-libsocket-dev" but I still get an error that says "/usr/bin/ld: cannot find -lsocket" any ideas ?
[04:59] <mohaa> bye you guys
[04:59] <mohaa> o/
[05:24] <det> Is it known if Lucid will ship with Mono 2.6 ?
[05:25] <det> It is currently using 2.4, and 2.6 was released in December and contains many bug fixes
[05:27] <micahg> det: it will probably be 2.4 as that's an LTS
[05:28] <micahg> det: 2.6 will most likely be in lucid +1
[05:28] <det> That is very unfortunate, but thanks for the info
[05:29] <micahg> det: it would be more unfortunate to have an unsupported version of mono in an LTS :)
[05:29] <det> What do you mean by unspported ?
[05:30] <micahg> det: mono only supports branches for certain amounts of time, so if we ship a short support branch in a long term release, then we'll have a period of time w/out upstream fixes/patches
[05:31] <det> Do you happen to know that Mono 2.4 is a long term support branch, while 2.6 not?
[05:31] <micahg> det: http://www.mono-project.com/Roadmap
[05:32] <det> I understand now, thanks.
[05:33] <micahg> det: np :), LTS's aren't the place for latest and greatest anyways..people want stability more than features in tehm
[05:33] <det> Perhaps some of the bug fixes I am interested in from 2.6 are backported into the 2.4.3 release
[05:33] <micahg> det: maybe and if they're not, maybe it can be requested
[05:34] <det> I will test out the Lucid alpha-2
[05:34] <micahg> det: alpha 3 is coming thursday
[05:35] <det> Well, I am interested in testing mono 2.4.3, which I think alpha-2 has
[05:36] <det> I tried 2.6 from a suse live cd, and it solved some problems in an application
[06:52] <pitti> Good morning
[06:52] <StevenK> Hi pitti!
[06:54] <pitti> bryceh, slangasek: so the two remaining use cases of hal in lucid are: (1) pitivi, and (2) gnome-power-manager uses hal to change the backlight on devices which don't have XBACKLIGHT support (which is still the majority)
[06:54] <pitti> slangasek, bryceh: hal was switched to d-bus activation, i. e. it does not start up on systems with xbacklight support on boot
[06:54] <pitti> slangasek: I'm afraid we are stuck with that in lucid
[06:55] <StevenK> pitti: I guess pitivi uses hal for hardware notifications?
[06:55] <pitti> yes
[06:55] <pitti> finding cameras, etc.
[06:55] <StevenK> Bleh
[06:55] <bryceh> pitti, is the xbacklight issue already known upstream?
[06:55] <StevenK> However, g-p-m is the much harder one to kill :-/
[06:56] <pitti> bryceh: yes, for a long time
[06:56] <bryceh> brb, gotta help put kiddo to bed
[06:56] <pitti> bryceh: it's a matter of getting driver support for it
[06:57] <pitti> argh! a dist-upgrade here wants to install chromium now, WTH?
[06:59] <StevenK> Wow, what's pulling that in ...
[06:59] <bryceh> pitti, any work arounds?  Can whatever hal does be extracted into something more standalone?
[06:59] <pitti> argh, nevermind
[07:00] <StevenK> pitti: False alarm?
[07:00] <pitti> bryceh: in theory yes, but in practice it'd be better to add xrandr support to drivers; otherwise you keep having two things which are responsible for the backlight control
[07:03] <bryceh> pitti, hmm, well waiting for stuff to get added to drivers (X drivers at least) can take a while...
[07:03] <pitti> right
[07:03] <pitti> but I think there's no way we can make even a workaround happen in lucid
[07:07] <dholbach> good morning
[07:11] <slangasek> pitti: ok, makes sense
[07:40] <Mamarok> is something wrong with the repo main server? it is extremely slow
[07:50] <nigel_nb> Mamarok: yep.  same here
[07:54] <mtx_init> to much tv
[08:30] <pitti> aah, I tracked down the reason for the major udisks boot time increase \o/
[08:30] <ogra> geez, our armel images exploded in size ... darn openoffice
[08:31] <pitti> ogra: when? which version of rhythmbox-ubuntuone-music-store do you have?
[08:31] <ogra> pitti, did we inherit the new langs from you guys ?
[08:31] <pitti> ogra: today's netbook images exploded by 40 MB, due to a wrong dependency in above
[08:31] <ogra> pitti, the image from 22 is 540 vs 690 today :)
[08:31]  * ogra check RB
[08:31] <pitti> ogra: we dropped most languages from our seeds
[08:32] <ogra> *checks even
[08:32] <ogra> +rhythmbox-ubuntuone-music-store 0.0.2-0ubuntu2
[08:32] <pitti> that's it
[08:32] <ogra> http://paste.ubuntu.com/382809/ is the manifest diff
[08:32] <pitti> ogra: you can substract 40 MB once  0.0.2-0ubuntu3
[08:32] <pitti> is published
[08:32] <ogra> ah, cool
[08:33] <ogra> still bloated :)
[08:33] <ogra> 540MB was so convenient :)
[08:33] <pitti> +default-jre 1.6-34
[08:33] <pitti> there you go
[08:33] <pitti> don't do that
[08:33] <ogra> i think that came in with oo.o
[08:33] <ogra> we didnt change our seeds at all, we only use what you guys use for netbook now
[08:33] <pitti> ogra: don't seed oo.o-base
[08:34] <persia> It's the *same* seed.
[08:34] <ogra> it will go again once the online office spec is fully implemented
[08:34] <ogra> until then we'll live with oo.o i guess ... its not oversized yet
[08:34] <pitti> hm
[08:34] <pitti> -base is not seeded
[08:35] <ogra> and 40MB less gets us back to 650 at least
[08:35] <pitti> so some wrong dependency pulls it back in
[08:35] <pitti> it's not on the i386/amd64 ones
[08:35] <ogra> strange
[08:35] <ogra> the seeds are identical, as persia stated abov
[08:35] <ogra> e
[08:36] <pitti> ogra: we recently had that problem on i386/amd64 as well
[08:36] <ogra> what was the issue ?
[08:36] <pitti> some oo.o translation package depended on language-support-writing-en | openoffice.org
[08:36] <pitti> something like that
[08:36] <pitti> but that got fixed during the sprint
[08:36] <ogra> weird, there shouldnt be any armel specific deps
[08:36] <pitti> it's definitively not a seed problem
[08:37] <pitti> +openoffice.org-report-builder-bin 1:3.2.0~rc4-1ubuntu1
[08:37] <pitti> nobody ever seeded stuff like that
[08:37] <ogra> Reverse Depends:
[08:37] <ogra>   openoffice.org-report-builder
[08:37] <ogra>   openoffice.org
[08:38] <ogra> hmm, the same on x86
[08:40] <pitti> ogra: perhaps some package is out of date on armel?
[09:19] <lifeless> pitti: in my laptops dmesg
[09:19] <lifeless> pitti: actually, I lie
[09:20] <lifeless> I was sshed into a linode ;P ignore that
[09:20] <pitti> hm, I'm pretty sure we disabled it in karmic
[09:20] <pitti> heh
[09:20] <lifeless> I do see udev spam on boot
[09:20] <lifeless> probably stale rules or something
[09:20] <pitti> lifeless: I see them from calibre
[09:20] <pitti> but I'm sure there's plenty of other broken/obsolete rules in packages out there :/
[09:21]  * pitti will fix calibre soono
[09:21] <pitti> s/o$//
[09:21] <lifeless> calibre? free californians?
[09:21] <pitti> heh
[09:21] <pitti> lifeless: e-book organizer/converter/creator
[09:22] <lifeless> nice
[09:22] <lifeless> I was trolling :>
[09:23]  * pitti remembers to stop taking you seriously from now on :)
[09:23] <pitti> lifeless: how's your Klingon these days?
[09:23] <lifeless> pitti: you should, when I'm not serious
[09:23] <lifeless> pitti: terrible, I don't know it
[09:23] <lifeless> pitti: I only set it up for you guys :>
[09:30] <lifeless> pitti: however, FF has a klingon pack too, now.
[10:50] <tseliot> cjwatson: any ideas as to why "DEB_SHLIBDEPS_INCLUDE_$(PKG_driver) := debian/$(PKG_driver)/$(DRIDIR)/fglrx/:/$(DRIDIR)/" doesn't work with cdbs in this case? http://pastebin.ubuntu.com/382879/
[10:50] <cjwatson> I don't really know cdbs ...?
[10:51] <tseliot> oh
[10:51] <cjwatson> maybe try 'export DH_VERBOSE=1' and run the relevant commands by hand to dig into it?
[10:52] <tseliot> cjwatson: ok, but you know debhelper. Basically what's happening here is that a binary depends on a library shipped by the same package
[10:52] <tseliot> ok
[10:52] <tseliot> by hand?
[10:53] <persia> tseliot: Since debian/control is not supposed to change at build-time, can't you just hardcode the dependency for that library into debian/control?
[10:53] <cjwatson> at a shell prompt
[10:54] <tseliot> persia: the binary and the library it depends on are in the same package
[10:55] <persia> tseliot: The same source package or the same binary package?
[10:55] <tseliot> persia: both things
[10:56] <persia> tseliot: Then why do you care about shlib:Depends there?  You know it's provided.  Just ship a symbols file for things that build against it.
[11:02] <persia> tseliot: If you're working around debug packages, you may want to request debhelper >= 6.0.3, but as long as you have debhlper >= 6.0.0 you shouldn't need -l anyway (which is what DEB_SHLIBDEPS_INCLUDE sets)
[11:03] <Noisi> hi there! i try to cross compile with arm-linux-gcc a sqlclient to arm720t and i need lib mysqlclient. Must i compile it from soucre? How?  it would give me great pleasure for some tip.
[11:03] <tseliot> persia: it's a proprietary library and it can get even messier. I've found out that my cdbs option works if I create a link (libfglrx_gamma.so.1) to libfglrx_gamma.so.1.0 (the actual library)
[11:04] <tseliot> persia: as the error was dpkg-shlibdeps: error: couldn't find library libfglrx_gamma.so.1
[11:04] <persia> tseliot: Ugh.  That's just messy.
[11:04] <tseliot> persia: welcome to the world of fglrx ;)
[11:05] <persia> Noisi: #ubuntu-arm might be a better forum.  There are precompiled binaries that might or might not work properly in a primarily cross-compiled environment.
[11:06] <Noisi> persia: Thanks :-)
[11:07] <tseliot> persia: with that link I don't even need DEB_SHLIBDEPS_INCLUDE_
[11:07] <persia> tseliot: So, you're operating with binary blobs?  I suspect a gap between filenames and information presented from introspection (nm might let you confirm).  Drop the -l, add the symlink, and generate a symbols file just to verify stuff.
[11:07] <persia> tseliot: Well, if you use debhelper 5 you'd still need it :)  The fix is with debhelper 6.  What's debian/compat?
[11:08] <tseliot> persia: 7
[11:08] <persia> Yeah, then you very much don't need DEB_SHLIBDEPS_INCLUDE
[11:09] <tseliot> cjwatson, persia: ok, thanks for your help
[11:14] <qense> If we would like to get bug #506125 fixed we'd have to sync Nautilus Actions, because the fix is in 2.29.4. Otherwise I'd remove nautilus-actions since it now just doesn't work. Will nautilus-actions be synced to 2.30 in time for the Lucid release?
[11:16] <cjwatson> Noisi: you might also like to look into dpkg-cross
[11:16] <cjwatson> (requires some setup)
[11:18] <soren> Keybuk: Mind if I bother you for a sec? In VMBuilder, I routinely mkfs some devmapper devices. Immediately afterwards, I use blkid to extract the uuid. Occasionally, blkid fails (exit code 2).
[11:18] <soren> Keybuk: I tried adding a "udevadm settle" in between the two, but it still happens every once in a while.
[11:18] <soren> It's rare, so I thought the "udevadm settle" fixed it, but it just happened again, so now I'm back to square 1.
[11:18] <Keybuk> soren: the mkfs will cause udev to run blkid itself, and rearrange symlinks
[11:19] <Keybuk> which way do you run blkid?
[11:19] <Keybuk> with -p or without?
[11:19] <Keybuk> if you run without, it's possible the cache is out of date
[11:19] <soren> without.
[11:19] <soren> Right.
[11:19] <Keybuk> right, run with -p
[11:19] <soren> Hm. I thought that was frowned upon.
[11:19] <Keybuk> you shouldn't need the settle
[11:19] <Keybuk> -p is a physical probe of the block device
[11:19] <soren> I thought the idea was that only udev would need to do that.
[11:19] <soren> I understand.
[11:19] <Keybuk> without means "whatever was in the cache"
[11:19] <Keybuk> yeah
[11:19] <Keybuk> but you need to wait for udev to do that
[11:20] <Keybuk> you can steal the wait-for-root code out of initramfs-tools if you like
[11:20] <Keybuk> that has the logic to wait properly
[11:20] <Keybuk> if you use that, you can just call blkid
[11:21]  * soren looks at that
[11:22] <soren> Can you explain why -p is needed? I thought that when mkfs let go of the device node, it would trigger an inotify event upon which udev would react, and that "udevadm settle" wouldn't return until udev was done processing this event (and thus, calling blkid -p and updating the blkid cache).
[11:22] <soren> Which part is mistaken?
[11:24] <soren> Keybuk: ^
[11:26] <Keybuk> that "udevadm settle" knows what you meant to wait for
[11:26] <soren> Keybuk: Could it be that my "udevadm settle" occurs before udev even sees the inotify event and thus does not think there are any unprocessed events?
[11:26] <Keybuk> udevadm settle simply waits for udev to be idle
[11:27] <Keybuk> events could be still somewhere en-route to udev
[11:27] <Keybuk> when we initially added the inotify stuff, it was true that udevd would force the inotify queue to be drained on settle
[11:27] <Keybuk> on the assumption that any file close instantly resulted in the entry being added to the inotify queue
[11:28] <Keybuk> but inotify has been entirely rewritten since then (replaced in-kernel with fsnotify)
[11:28] <Keybuk> so that may no longer be true
[11:28] <Keybuk> it might be possible for there to be a gap between the mkfs call, and the inotify event being queued for udev to receive
[11:29] <soren> Right, ok.
[11:29] <Keybuk> it would be worth reading some kernel code to find out whether or not that's changed
[11:30] <soren> Keybuk: You said "when we initially added the inotify stuff, it was true that udevd would force the inotify queue to be drained on settle"... Does it not attempt to drain this queue anymore? (Yes, I understand that the event might not be in the queue at all yet, this is just a side-question)
[11:30] <Keybuk> soren: udevd does, yes
[11:30] <soren> Ok.
[11:31] <Keybuk> *inotify*, in the kernel, has been completely rewritten
[11:31] <Keybuk> so it's possible that the act of mkfs closing the device node does queuey things in the kernel
[11:31] <Keybuk> that no longer guarantees that udevd's inotify socket polls for reading *by the time close() returns*
[11:31] <Keybuk> if that bit has gone async in the kernel, you'd have a race where after mkfs exits, udevd may not yet have received the inotify event for the block device
[11:32] <soren> *nod*
[11:33] <Keybuk> that'd be worth some investigation
[11:39] <soren> Keybuk: udev still uses the inotify /interface/, right?
[11:40] <Keybuk> yes
[11:40] <soren> alright
[11:42] <cjwatson> Keybuk: so yesterday I started converting console-setup to upstart in order to fix its interaction with plymouth, which is a little bit involved due to how it glues into the installer.  Am I duplicating work you've already done and should I stop? :-)
[11:42] <cjwatson> (I didn't get very far as it was at the end of the day - just wrote initial job sketches)
[11:44] <Chipzz> Keybuk: ugh, too much *notify's and fa*'s ;P
[11:44] <Chipzz> starting to get really confusing :)
[11:44] <Keybuk> cjwatson: no, you're doing work I felt was far too scary for me ;P
[11:44] <Keybuk> I couldn't work out when we'd actually run console-setup
[11:44] <Keybuk> since plymouth is *always* running from startup through to power off
[11:44] <Keybuk> I thought we might need to use ConsoleKit to run console-setup when switching away from X
[11:44] <Chipzz> inotify, dnotify, fanotify, fam...
[11:44] <Chipzz> which ones am I forgetting? :P
[11:45] <Chipzz> fsnotify
[11:45] <Keybuk> Chipzz: fam is not a kernel interface
[11:45] <Keybuk> Chipzz: and all those you mentioned are the same in-kernel code
[11:45] <Keybuk> just different user-space interfaces for the underlying fanotify code
[11:45] <Keybuk> or is it fsnotify
[11:45] <Chipzz> Keybuk: I know, but all these technologies fall into the same "realm"
[11:45] <Keybuk> Chipzz: they're all the same technology from the kernel POV
[11:45] <Chipzz> just different iterations :P
[11:45] <Keybuk> the difference between inotify, dnotify and fanotify is the difference between open(), creat() and socket()
[11:46] <Keybuk> no, not even iterations
[11:46] <Keybuk> *the same code*
[11:46] <cjwatson> Keybuk: I was thinking of running it 'on starting plymouth-splash'
[11:46] <cjwatson> roughly
[11:46] <Chipzz> wasn't dnotify replaced by inotify?
[11:46] <Chipzz> s/replaced/obsoleted/
[11:47] <soren> Chipzz: Yes.
[11:47] <Keybuk> Chipzz: dnotify was implemented using inotify
[11:47] <soren> Chipzz: And then inotify was replaced by fsnotify.
[11:47] <Keybuk> cjwatson: right, that's about the only point we can do it
[11:47] <Keybuk> the problem then is racing gdm
[11:47] <Keybuk> you could be doing console-setup and hold up plymouth --show-splash
[11:47] <Keybuk> meanwhile gdm starrs
[11:47] <Keybuk> and starts X
[11:48] <cjwatson> this would suck less if the kernel sucked less
[11:48] <cjwatson> it's ridiculous that we need an active text-mode console in order to set the console font
[11:49] <Keybuk> agree
[11:49] <Keybuk> it would suck less if upstart sucked less too
[11:50] <cjwatson> using consolekit would sort of work, but wouldn't be effective on server-type installations
[11:50] <cjwatson> since ttx filed the bug in question ... :-)
[11:50] <cjwatson> (well, one instance of it)
[11:50] <Keybuk> well, on server plymouth does exit at the end of rc2
[11:50] <Keybuk> so that's one obvious place to run console-setup
[11:50] <cjwatson> yeah, true
[11:51] <cjwatson> we used to do that for usplash
[11:51] <cjwatson> could shove it in plymouth's stop script
[11:51] <Keybuk> it's desktop that's tricky, because getting to a console is really only by C-A-F1
[11:51] <Keybuk> cjwatson: on stopping plymouth plz :p
[11:51] <cjwatson> fair enough :)
[11:51] <Keybuk> shoving other things into upstart scripts is not the upstart way ;)
[11:52] <cjwatson> ok, so I'm happy to make this my problem if I'm not stepping on your toes and you don't mind occasional requests for criticism
[11:52] <Keybuk> sure
[11:52] <Keybuk> I'm happy for it to be your problem
[11:52] <Keybuk> gives me more time for plymouth itself to be my problem <g>
[11:52] <cjwatson> maybe I should just fix the damn kernel
[11:52] <Keybuk> Jim Leib tried that
[11:52] <Keybuk> he died
[11:53]  * cjwatson is not Jim Lieb
[11:53] <cjwatson> :-)
[11:53]  * ogra grins
[11:53] <Keybuk> no, indeed; you're unlikely to have to learn ANSI C just to read the kernel source
[12:01]  * sebner has faith in our mighty cjwatson :D
[12:02] <cjwatson> well, this is something that's defeated me in the past, so we'll see
[12:02] <cjwatson> the basic problem (AFAICR) is that vgacon stores the font only in video memory
[12:10] <Keybuk> we're not using vgacon anymore though, right?
[12:10] <Keybuk> we're always using fbcon
[12:13] <cjwatson> Keybuk: for a kernel bug report, I'd want to cover all possibilities
[12:13] <cjwatson> *kernel patch
[12:14] <cjwatson> Keybuk: and that's the basic reason why there's a != KD_TEXT guard in console-impl-independent code
[12:14] <Keybuk> yeah, I recall
[12:14] <Keybuk> didn't we find a different ioctl() that didn't have that guard?
[12:14] <Keybuk> my memory on this is hazy
[12:15] <Keybuk> though that may be the fact I just downed 8 different tablets ... whee drugs :p
[12:40] <cjwatson> Keybuk: I don't remember that, though that's not to say it didn't happen - I'd rather fix it so it doesn't need the guard though :)
[12:42] <Keybuk> right
[12:57] <seb128> "ubi-partman failed with exit code 141"
[12:57] <seb128> I guess it's not today I will manage to reinstall that mini
[12:58] <seb128> "Device /dev/sda1 not found is os-prober"
[12:58] <seb128> "Device /dev/sda1 not found is os-prober output"
[12:58] <seb128> rather
[12:59] <seb128> what component should be bugged about that?
[12:59] <cjwatson> device not found> irrelevant message
[12:59] <cjwatson> bug on nubiquity
[12:59] <cjwatson> *ubiquity
[13:00] <cjwatson> please reproduce with debug-ubiquity on the kernel command line before filing the bug, and use ubuntu-bug from within the live session to file it
[13:03] <seb128> cjwatson, ok will do
[13:14] <pitti> cjwatson: gnome-user-share does not have any uploaders in edit_acl at all; can you please fix this?
[13:20] <lamont> some of the ppa buildds are undergoing a little maintenance atm.  Just fyi
[13:21] <dholbach> bryceh: could it be that your script went beserk on bug 520796? :)
[13:27] <uelapeppa> hi
[13:31] <balboa> hi
[13:34] <balboa> i've tried to make an ubuntu lucid remix folowing this how-to :https://help.ubuntu.com/community/LiveCDCustomizationFromScratch but when i try to install it i get "AssertionError: Missing filesystem.size." from ubiquity
[13:35] <seb128> cjwatson, bug #527057
[13:35] <seb128> seems similar to bug #525081
[13:36] <seb128> "PartmanOptionError: partman/choose_partition should have finish (None) option"
[13:37] <seb128> cjwatson, I get the issue every time on the mini so let me know if you need any detail
[13:40] <ev> balboa: you need /casper/filesystem.size on your CD.
[13:41] <balboa> ev: and how can i create it?
[13:42] <ev> well, if you haven't changed the squashfs at all, you can simply reuse the existing one.  If you have changed the squashfs, then:   printf $(du -sx --block-size=1 /path/to/the/mounted/squashfs | cut -f1) > filesystem.size
[13:45] <balboa> ev: i made the iso from scratch so for "/path/to/the/mounted/squashfs" can i use the path of my chroot?
[13:45] <ev> (updating that wiki page now with this)
[13:45] <ev> yes
[13:46] <balboa> ev: thank you =) i'll try it
[13:46] <ev> balboa: sure thing
[13:46] <ev> good luck! :)
[13:49] <pitti> ev: oh, nice! the keymap guesser is in ubiquity now
[13:50] <balboa> ev: i get some errors from du : it can't read some directories
[13:50] <ev> balboa: stick a sudo in front of it
[13:50] <ev> printf $(sudo du...
[13:50] <ev> pitti: yup :)
[13:51] <cjwatson> pitti: gnome-user-share> done
[13:51] <pitti> cjwatson: cheers
[13:51] <pitti> chrisccoulson: ^ FYI
[13:51] <chrisccoulson> pitti / cjwatson - thanks
[13:51] <balboa> ev: i'm stupid -.- i've put sudo in front of printf
[13:52] <chrisccoulson> pitti - is that part of the packageset i can upload?
[13:52] <pitti> chrisccoulson: edit_acl says ubuntu-desktop, yes
[13:52] <chrisccoulson> cool, thanks:)
[13:53] <pitti> chrisccoulson: when will you apply for core-dev?
[13:53] <chrisccoulson> pitti - soon hopefully
[13:53]  * pitti holds up his fanboy cardboard sign
[13:54] <chrisccoulson> heh :)
[13:58] <seb128> chrisccoulson++
[14:00] <ogra> Keybuk, i see "ureadahed-main terminated" messages on boot of armel live images, do i need to worry ? (i dont see that on installed systems, ureadahread seems to work fine there)
[14:01] <ogra> (do we actually use it in live images)
[14:01] <Keybuk> ogra: what exit code?
[14:04] <ogra> i have to reboot for that, gimme a bit
[14:05] <cjwatson> seb128: investigating
[14:05] <seb128> cjwatson, thanks
[14:05] <ogra> Keybuk, it says status 4
[14:06] <ogra> wow, JamieBennett is a hero, the live image on armel boots really really fast !
[14:06] <Keybuk> ogra: that's ok, that's just ureadahead saying "I don't have anything to read for this mount point"
[14:06] <ogra> 1:48 ... vs ~4min in karmic
[14:07] <ogra> Keybuk, perfect, thanks
[14:07] <cjwatson> seb128: ah.  bug occurs when there is a partition that partman doesn't know how to resize
[14:07] <seb128> cjwatson, it shouldn't need to resize anything in my case though?
[14:08] <seb128> cjwatson, I delete one partiton and use the space to create a new one + a swap
[14:08] <cjwatson> seb128: sure, but it still scans
[14:08] <seb128> ok
[14:08] <cjwatson> it's the cache-building bit that falls over
[14:08] <seb128> let me know if you want me to test a fix or something
[14:08] <cjwatson> are you in a position to edit a file before ubiquity starts?
[14:08] <seb128> cjwatson, yes, I'm back to livecd desktop
[14:09] <seb128> I can edit and run ubiquity again
[14:09] <cjwatson> seb128: you'd probably better restart in "try ubuntu" mode, I don't want to deal with possible wreckage in the live session
[14:09] <seb128> ok, doing that
[14:09] <seb128> it's an usb key so it's quick to boot ;-)
[14:10] <cjwatson> seb128: could you apply http://paste.ubuntu.com/382990/ to /usr/lib/ubiquity/plugins/ubi-partman.py, please?
[14:11] <zul> james_w: thanks for the samba branch
[14:12] <james_w> zul: it's a little out of date at the moment due to dpkg-dev weirdness, looking in to it right now
[14:12] <seb128> cjwatson, ok, trying that
[14:12] <zul> james_w: cool
[14:18] <seb128> cjwatson, that seems to work, at least I can get to the next screen without error now
[14:18] <seb128> cjwatson, continuing the install, I will let you know how it works
[14:19] <seb128> bah
[14:19] <seb128> ubiquity segfault now
[14:19] <seb128> is apport running on the livecd?
[14:20] <seb128> pitti, ^
[14:20] <pitti> seb128: yes, it is
[14:20] <cjwatson> segfault?  it's python
[14:20] <cjwatson> iz gtk bug?
[14:21] <seb128> cjwatson, http://paste.ubuntu.com/382995
[14:21] <seb128> cjwatson, iz glib bog? ;-)
[14:21] <seb128> I don't get a .crash though
[14:21] <james_w> zul: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558485
[14:22] <james_w> zul: that's not fixed in hardy where it matters for this, so I will have to implement a workaround.
[14:22] <cjwatson> seb128: committed the fix for 527057 anyway, thanks
[14:22] <seb128> cjwatson, thanks!
[14:22] <zul> james_w: sounds good to me
[14:22] <cjwatson> seb128: mm, a few people have reported that kind of thing, I'd tentatively put it down to image errors but if you're seeing it maybe you can figure out what's causing it?
[14:22] <seb128> cjwatson, I will try, shame that apport is not working
[14:23] <seb128> bah, it works if I kill -11 gedit
[14:26] <Laney> is archive.u.c sick?
[14:26] <james_w> yes
[14:27] <seb128> cjwatson, any idea what process I should use gdb on?
[14:27] <seb128> cjwatson, ubiquity exit with code 0377
[14:27] <seb128> I've gdb --args python /usr/bin/ubiquity
[14:28] <cjwatson> that'll miss privilege elevation
[14:28] <seb128> ok
[14:28] <cjwatson> err
[14:28] <seb128> let me start again
[14:28] <seb128> and sudo gdb -p it
[14:28] <cjwatson> you probably want:
[14:28] <cjwatson> sudo -E devkit-disks --inhibit -- gdb --args /usr/bin/python /usr/lib/ubiquity/bin/ubiquity
[14:28] <cjwatson> or something like that
[14:29] <cjwatson> though yes, attaching to the running process would probably be easier
[14:29] <didrocks> cjwatson: thanks for the netbook seed fix :)
[14:29] <cjwatson> no problem, hope it works ;-)
[14:39] <seb128> cjwatson, http://paste.ubuntu.com/383006/ not really useful ...
[14:40]  * seb128 tries valgrind
[14:40] <cjwatson> public service announcement: please can everyone STOP trying to find an existing ubiquity bug report that describes their problem and attaching logs to it
[14:40] <cjwatson> just file new bugs
[14:41] <cjwatson> suggests that a main loop source got trashed?
[14:42] <cjwatson>           prepare = source->source_funcs->prepare;
[14:42] <seb128> could be yes
[14:42] <geser> bryceh: do you really need the xorg.log and the output from lspci for a bug about a insufficient dependency (bug 507618)?
[14:43] <cjwatson> seb128: do you think I should go ahead with a ubiquity upload for a3 anyway, to get rid of the partitioning bug, or do you think this is likely to need a change in ubiquity?
[14:44] <seb128> cjwatson, I've no real clue about this crasher atm, I would guess it's an ubiquity issue though since we didn't get similar bugs otherwise
[14:45] <cjwatson> I don't understand how python code could cause a segfault unless the python binding libraries are broken
[14:45] <seb128> cjwatson, still I'm not sure the crash bug will be fixed quickly and since it doesn't happen to everybody I would fix the partioning issue to start
[14:45] <cjwatson> ubiquity used to have some python bindings of its own, but we got rid of those a while back
[14:46] <seb128> cjwatson, well you could be doing something wrong, like using gtk after exiting the mainloop
[14:46] <cjwatson> ok, I'll upload .27 then
[14:46] <seb128> cjwatson, pygtk tends to not handle always such cases in a pythonish way, ie raise exceptions
[14:46] <seb128> it rather crashes
[14:47] <seb128> same if you try using gtk without a display set
[14:47] <cjwatson> hmm, I suppose that's possible
[14:47] <cjwatson> we do some funny things with the main loop
[14:47] <cjwatson> could I get a separate bug for this with debug logs?
[14:47] <seb128> cjwatson, yes, let me try to valgrind first :-)
[14:48]  * cjwatson nods
[14:48] <seb128> $ unset DISPLAY; alacarte
[14:48] <seb128> Erreur de segmentation (core dumped)
[14:48] <seb128> just as an example of pygtk is not friendly with errors ;-)
[14:49] <cjwatson> main loop's a bit more likely, DISPLAY isn't going to get magically unset :-)
[14:49] <seb128> right
[14:49] <seb128> bah, installing valgrind on the livecd = fail
[14:49] <seb128> enospace
[14:50] <cjwatson> mine more memory
[14:50] <kirkland> pitti: re: https://bugs.launchpad.net/bugs/503180, could you nudge that karmic-proposed eucalyptus to karmic-updates?  I have another SRU pending for upload to -proposed ;-)
[14:50] <cjwatson> or --no-install-recommends, it might not really need libc6-dbg too badly
[14:50] <cjwatson> oh, that's a depends, ignore me
[14:52] <pitti> kirkland: ah, it's just 7 days old today, fine; moving
[14:52] <kirkland> pitti: cheers, thanks ;-)  i've been keeping my eye on it ;-)
[14:57] <pitti> didrocks: ah, so you broke the armel netbook images ;)
[14:58] <didrocks> pitti: me? sure? :-)
[14:58] <pitti> didrocks: please don't seed language-support-${Languages} for anything else but -en
[14:58] <pitti> language-support-* is huge, and it also pulls in the entire openoffice.org including java
[14:58] <pitti> ogra: ^ FYI
[14:59] <didrocks> pitti: oh, so we need to add [!armel] to the language pack?
[14:59] <didrocks> (there was -en and -es before my change, FYI)
[14:59] <ogra> didrocks, oh, pleasse dont :)
[14:59] <ogra> we want the translations on armel as well
[14:59] <pitti> --- live2010-02-22 16:00:21 +0000
[14:59] <pitti> +++ live2010-02-24 14:59:02 +0000
[14:59] <pitti> - * language-support-${Languages}
[15:00] <pitti> ogra, didrocks: r1448 in netbook.lucid seed
[15:00] <ogra> didrocks, the prob is that -support pulls in *everything*, you only want the stuff thats actually needed on a live image for space reasons
[15:01] <didrocks> pitti: ogra: but it was there before (see in r1441.1.3), only with -es
[15:01] <ogra> didrocks, there should be -en but no other langs
[15:01] <didrocks> pitti: ogra: I just add aditionnal language, is there an exception of -es so?
[15:02] <pitti> didrocks: no, l-support-es shouldn't be there either
[15:02] <ogra> no, -en is the only language we fully install
[15:02] <pitti> but -es doesn't have a hyphenation package
[15:02] <pitti> didrocks: language-pack-* is okay; language-support-* is a no-go for shipping
[15:03] <seb128> cjwatson, while looking around I found an another issue, you call devkit-disks in ubiquity
[15:03] <seb128> cjwatson, there is no such command now, it's "udisk"
[15:04] <didrocks> pitti: so, it was an error on the previous version of the seed, right? The issue was just not triggered because -es has no hypenation package?
[15:04] <seb128> cjwatson, do you want a bug about that? or just fix it now?
[15:04] <pitti> argh, sorry about that
[15:04] <pitti> it's "udisks", not "udisk"
[15:04] <seb128> ups
[15:04] <pitti> I checked through the reverse depends, but since it's not a dependency that slipped my attention
[15:04] <cjwatson> seb128: ah, I can fix that now, no need for a bug
[15:05] <seb128> cjwatson, thanks
[15:05] <seb128> cjwatson, it's udisks (plurial as pitti pointed before)
[15:05] <seb128> I guess you will get it right but just pointing in case ;-)
[15:06] <pitti> cjwatson: it's a pure rename of the command, CLI syntax stayed the same
[15:08] <cjwatson> yep - committed
[15:27] <imran> hello
[15:45] <rbrunhuber> hi, is there a list of feature freeze exceptions for lucid and more important does it contain php5.3?
[15:54] <zul> rbrunhuber: im in the process of doing it
[15:55] <rbrunhuber> zul : The list or the ffe for php5.3?
[15:55] <zul> rbrunhuber: working on the ffe for php5.3
[15:59] <rbrunhuber> zul: How likely do you think is it that the ffe is getting approved?
[16:00] <zul> rbrunhuber: no idea
[16:01] <qense> Python 2.5 was removed from Lucid?
[16:02] <nigelb> qense: yes
[16:02] <qense> nigelb: ok, thanks
[16:04] <rbrunhuber> zul : Is there anything I can do to help you with the ffe?
[16:04] <zul> rbrunhuber: nope you just have to be patient
[16:04] <rbrunhuber> zul : Ok, thanks.
[16:15] <didrocks> jono: around? I heard you plan to do a new lernid release today? (so that I can push it into universe)
[16:16] <jibel> mvo, hi, I pushed a fix for the xapian search in synaptic. Could you please review it when you have a minute ?
[16:18] <jibel> mvo, it fixes relevancy of the results, large performance improvement and add boolean operators.
[16:18] <mvo> jibel: yes, I merged it locally already, looks fine, but I did not have time for a proper review
[16:19] <mvo> jibel: the relevance set is now gone, right? I'm not sure of how much practial value it really is/was, but it was meant to improve things when debtags is around
[16:20] <jibel> mvo, it's still there but user configurable.
[16:20] <cjwatson> Riddell: did you mean to close bug 526534 in your ubiquity upload?  you used a syntax in the changelog that does not close the bug
[16:21] <jibel> mvo, I mainly dropped the expansion stuff since it's done by xapian.
[16:21] <Riddell> cjwatson: no, hiding the progress bar is a workaround, I'd like to find the cause after the alpha
[16:21] <mvo> jibel: aha, ok. I need to have a proper look :) thanks a lot for working on it
[16:21] <jibel> mvo,  and limit the resultset based on the estimate returned by the search engine.
[16:22] <cjwatson> Riddell: ok.  and should bug 526456 still be alpha-3?
[16:23] <cjwatson> Riddell: I'll move 526534 to beta-1, then
[16:24] <Riddell> 526456 can be moved to beta-1 as well
[16:24] <cjwatson> ok
[16:25] <cjwatson> done
[16:26] <jono> didrocks, hey, on a call, but yep, planning on a release :)
[16:26] <jono> didrocks, will ping you in a bit
[16:26] <mbudde> jono: I'd like a have a talk with you too :)
[16:26] <didrocks> jono: cool :)
[16:26] <jono> mbudde, yeah, sorry for the delay on Lernid - I was traveling last week
[16:27] <jono> mbudde, I think just a little more visibility on the tweet button and we are good to go
[16:27] <didrocks> mbudde: do you have a FFe under the hand? do you need some help? :)
[16:28] <mbudde> didrocks: sorry, haven't started on it yet.
[16:31] <pitti> seb128: is bug 527098  what you got as well?
[16:31] <pitti> (just spotted from the iso tracker)
[16:32] <seb128> pitti, yes
[16:32] <pitti> seb128: is that a dupe then? or did you just debug it on IRC?
[16:33] <seb128> pitti, I didn't open the bug yet, I've been fighting to get details but the bt is useless
[16:33] <seb128> and valgrind doesn't work
[16:33] <seb128> I can't go pass the partitionning stage when running valgrind
[16:33] <pitti> ok, fine; well, then that is "the" bug report
[16:34] <seb128> pitti, not quite, I will open one with ubuntu-bug debug infos
[16:34] <cjwatson> well, "a" bug report
[16:34] <cjwatson> one with ubuntu-bug will likely be a bit more useful :)
[16:34] <seb128> I'm just redoing my key and upgrading to .27
[16:34] <pitti> absolutely
[16:34] <seb128> I did too many hacking changes to get valgrind running
[16:34] <pitti> seb128: good luck!
[16:34] <seb128> like unpack in tmp and ln in usr
[16:35] <lool> cjwatson: endianess issue > not sure, the initrd was built on real hardware (buildd) and the kernel as well, so I'm not sure why these would suddenly be wrong; did you have a particular explanation in mind?
[16:35] <cjwatson> just a vague memory that cpio endianness is funny
[16:35] <cjwatson> I've written assembler code to byte-swap it
[16:35] <cjwatson> I thought the kernel dealt with that though
[16:47] <james_w> "Unable to read [...] FileExists (2: No such file or directory)" <- nicely done
[16:57] <Keybuk> pitti: did you do any investigation into this rsyslog bug?
[16:58] <pitti> Keybuk: I sketched what the daemon would need to do, but no C implementation
[16:58] <Keybuk> pitti: but it does that already
[16:58] <pitti> i. e. seteuid(rsyslog), read()
[16:58] <Keybuk> it has this whole klogWillRun() thing
[16:58] <pitti> EPERM -> seteuid(0), keep it
[16:58] <pitti> works -> setuid(rsyslog) to drop permanently
[16:58] <Keybuk> so if it gets EPERM, it should just disable klog
[16:58] <Keybuk> not spin
[16:59] <pitti> I didn't look at that
[17:01] <cjwatson> when it happened to me, rsyslog itself didn't seem to be spinning, but the entire rest of the system slowed to a crawl, load average went through the roof, and I had to reboot
[17:01] <cjwatson> I can't prove it was rsyslog, but it was right after the rsyslog package was upgraded
[17:01] <cjwatson> I wasn't really in a position to debug it accurately, but I speculated that everything else was getting stuck on full buffers or something
[17:02] <Keybuk> but this is only klog, the thing that picks up dmesg
[17:02]  * ogra thought that was a missing kernel feature or was that a different bug ?
[17:02] <ogra> i definately saw rsyslogd eating 100% CPU when it hit me on armel
[17:02] <pitti> ogra: it's fixed in current lucid kernel and in linux trunk
[17:03] <seb128> today is ubiquity bug day
[17:03] <pitti> but not during upgrade, etc.
[17:03] <ogra> pitti, right and in the imx51 .31 kernel
[17:03] <ogra> where we only saw it last week
[17:03] <pitti> Keybuk: isn't it all just one process in rsyslog?
[17:03] <Keybuk> pitti: no, rsyslog seems very modulised
[17:04] <pitti> I only have a single rsyslogd -c4 process here
[17:04] <pitti> which has fds to /proc/kmsg as well as /var/log/*.log
[17:04] <Keybuk> sure, but internally it's doing everything through a linked list of structs, etc.
[17:05] <Keybuk> if it can't open the klog thing, afaict, it will be just missing that module
[17:05] <Keybuk> which is odd for "CONSUMES 100% CPU ARGH!"
[17:05] <Keybuk> :p
[17:05] <pitti> Keybuk: it can certainly open it
[17:05] <Keybuk> oh, the open() doesn't fail, the read() does?
[17:05] <pitti> Keybuk: rsyslogd starts as root, opens files, keeps fds, and then drops prifs
[17:05] <pitti> privs, even
[17:05] <pitti> and then read() fails with EPERM
[17:05] <pitti> (see bug description)
[17:05] <Keybuk> pitti: not entirely sure that's true
[17:05] <Keybuk> runInputModules() happens *after* the de-rooting
[17:06] <Keybuk> pitti: the bug description isn't very helpful
[17:06] <pitti> but if it would drop privs before opening /proc/kmsg it wouldn't work on current lucid at all
[17:06] <Keybuk> Feb 18 05:04:22 ubuntu kernel: last message repeated 1327321 times
[17:06] <Keybuk> is about as much detail as it gives :p
[17:07] <Keybuk> pitti: I don't follow?
[17:07] <Keybuk> ah, no, I see
[17:07] <Keybuk> the fact this works is an accidental side-effect of testing to see whether it works :p
[17:07]  * Keybuk is guessing deroot.patch is yours?
[17:07] <pitti> Keybuk: right now it seems to open() as root and read() as rsyslog
[17:08] <pitti> Keybuk: no, I never touched rsyslog
[17:08] <Keybuk> hmm, the deroot.patch is ubuntu-specific
[17:08]  * pitti rtfs
[17:08] <Keybuk> ah, it's mterry's
[17:08] <Keybuk> pitti: yeah that'd fit
[17:08] <Keybuk> current lucid - you need to open as root?
[17:08] <pitti> right
[17:09] <pitti> -r-------- 1 root root 0 2010-02-24 07:42 /proc/kmsg
[17:09]  * seb128 files bug #527199 now
[17:09] <pitti> Keybuk: in previuos kernels, the bug was that not only the open(), but also the read() needed root privs
[17:09] <pitti> Keybuk: which is why we needed that dd process to shovel it to a fifo
[17:09] <Keybuk> ok
[17:09] <Keybuk> so I don't see at all what you thought might work
[17:09] <pitti> now it behaves as usual, open() obeys file perms, and read() just needs an fd, without checking capabilities
[17:10] <pitti> Keybuk: so on an older kernel, read() will -EPERM
[17:10] <Keybuk> ok
[17:10] <pitti> so one possibility would be to just stop the klog module on that
[17:10] <Keybuk> yeah, that seems the only possibility here
[17:10] <pitti> the other would be to temporarily drop privs with seteuid(rsyslog), do the first read() (or peek()), check for -EPERM, and then re-raise or permanently drop privs
[17:11] <Keybuk> there is no peek()
[17:11] <pitti> which would work on older kernels as well
[17:11] <Keybuk> that read() could cause rsyslog to block forever
[17:11] <pitti> but is more tricky to implement
[17:11] <Keybuk> if there was no kernel log pending, or the level was set high, then the read() would forever block waiting for data
[17:11] <pitti> Keybuk: right, it'd require some fcntl with O_NONBLOCK, etc.
[17:11] <Keybuk> if you read non-blocking, it'd return EAGAIN not EPERM
[17:11] <pitti> that's where the "more tricky to implement" bit comes in :)
[17:11] <Keybuk> then suddenly when there was data, EPERM and go back to 100% CPU
[17:12] <pitti> Keybuk: "EAGAIN not EPERM" > are you sure?
[17:12] <Keybuk> pitti: yes
[17:12] <Keybuk> reasonably
[17:12] <pitti> the kernel capability check was pretty early
[17:12] <Keybuk> it's certainly *permitted* to return EAGAIN without a cap check
[17:12] <Keybuk> and we wouldn't want to rely on kernel behaviour here
[17:13] <pitti> Keybuk: and in the python snippet on bug 515623  I had read() block as well (when running as root)
[17:13] <pitti> but immediately -EPERMing as non-root
[17:13] <pitti> it didn't block
[17:13] <pitti> Keybuk: but even if it does, certainly rsyslog currently has blocking calls as well?
[17:13] <pitti> the blocking shouldn't really matter
[17:13] <pitti> it just needs a little state machine to remember whether it's the first read
[17:14] <Keybuk> I don't think we can unload modules looking at this
[17:14] <Keybuk> once the module is loaded, it looks like it's impossible to unload it
[17:14] <Keybuk> too many unprotected linked lists
[17:14] <Keybuk> it'd turn 100% CPU into SIGSEGV
[17:14] <pitti> ok, let's not do that then
[17:15] <Keybuk> I wonder what read(0) would do here
[17:16] <Keybuk> >>> import os
[17:16] <Keybuk> >>> fd = os.open("/proc/kmsg", os.O_RDONLY)
[17:16] <Keybuk> >>> os.read(fd, 0)
[17:16] <Keybuk> ''
[17:16] <Keybuk> >>> os.seteuid(1000)
[17:16] <Keybuk> >>> os.read(fd, 0)
[17:16] <Keybuk> Traceback (most recent call last):
[17:17] <Keybuk>   File "<stdin>", line 1, in <module>
[17:17] <Keybuk> OSError: [Errno 1] Operation not permitted
[17:17] <Keybuk> --
[17:17] <Keybuk> that seems to work
[17:17] <Keybuk> whereas
[17:17] <Keybuk> >>> os.seteuid(0)
[17:17] <Keybuk> >>> os.read(fd, 0)
[17:17] <Keybuk> ''
[17:17] <Keybuk> >>> os.read(fd, 1)
[17:17] <Keybuk> (still blocking)
[17:17] <pitti> "If  count is zero, read() returns zero and has no other results. "
[17:17] <pitti> but if it -EPERMs, that's great
[17:17] <Keybuk> sure, but it should at least go through the cap check ;)
[17:17] <pitti> makes it much easier to imiplement
[17:18] <pitti> bah, tpying is hrad
[17:18] <Keybuk> ok, so that's the trick then
[17:18] <Keybuk> do a zero-byte read after opening
[17:18] <Keybuk> if we get EPERM, then decline
[17:18] <pitti> s/decline/not drop privs/?
[17:19] <Keybuk> no, don't think we can do that
[17:19] <Keybuk> drop privs is WWWWAAAYYY above this code
[17:19] <Keybuk> just decline to do kernel logging
[17:19] <Keybuk> this is inside an alternate backend code, inside a module, inside a configurable part of the build tree, etc.
[17:20] <Keybuk> and for the upgrade case, rsyslog has already dropped privs, it can't undecide ;)
[17:20] <pitti> fair enough
[17:21] <pitti> Keybuk: no, we restart rsyslogd on upgrade (that's where the problem comes from in the first place)
[17:21] <Keybuk> ah ok
[17:21] <pitti> Keybuk: we could _not_ restart rsyslogd on upgrades with an older kernel running
[17:21] <pitti> if we want to retain kern.log for upgrade bug reports, or anythign like that
[17:21] <Keybuk> the point still stands though that it's already decided whether or not to drop privs before it loads modules
[17:22] <Keybuk> extending the rsyslog module interface just to let modules say "hey, I can't!" seems like a massive patch
[17:22] <pitti> right, which makes it hard to work with older kernels
[17:22] <Keybuk> adding a read(0) to the "will the klog module work" function seems much easier
[17:22] <pitti> so let's not do that
[17:22] <pitti> that> turn the implementation upside down, I mean
[17:23] <pitti> Keybuk: oh, it just occurs to me that most apport bugs use dmesg anyway instead of attachign kern.log
[17:23] <pitti> so that should be fine
[17:24] <Keybuk> yeah, I just don't see a way of doing what you suggest
[17:24] <Keybuk> rsyslog just isn't engineered that way
[17:27] <pitti> Keybuk: at the time when it opens /proc/kmsg, can it reach its option dictionary? it coudl do the read() test there, and unset the "drop privileges" option?
[17:28] <pitti> but oh well, not having klog when running older kernels doesn't seem like a big issue
[17:29] <Keybuk> pitti: no, it can't
[17:29] <cjohnston> mbudde: ping
[17:29] <mbudde> cjohnston: pong
[17:29] <Keybuk> /proc/kmsg is opened in the "is this module supported on this system?" function
[17:29] <Keybuk> it doesn't have config or anything yet
[17:29] <Keybuk> modules only get that in other functions fwictr
[17:30] <Keybuk> but again, it doesn't change the fact that main() is already in a different if() statement because it's decided to be de-rooted
[17:30] <cjohnston> Hey dude.. We had a couple ideas for Lernid if you have a few.. based on some things with ClassBot
[17:30] <mathiaz> cjohnston: hi - does grub2 support booting from devices part of a raid1 array?
[17:30] <cjohnston> I dunno
[17:30] <mathiaz> cjwatson: hi - does grub2 support booting from devices part of a raid1 array?
[17:30] <mathiaz> cjohnston: sorry - wrong nickname
[17:30] <cjohnston> I figured.. ;-)
[17:31] <cjwatson> mathiaz: in general I think so, but there are some known bugs, like it doesn't support the latest mdadm metadata format
[17:32] <mathiaz> cjwatson: hm - would this be the reason why grub-install would fail?
[17:32] <mathiaz> cjwatson: http://paste.ubuntu.com/383141/
[17:32] <cjwatson> err buggadifino
[17:33] <cjwatson> grub-install --debug might be a bit more informative
[17:35] <cjwatson> actually, that's weird
[17:35] <cjwatson> I think you should just install to /dev/md0
[17:35] <mathiaz> cjwatson: that's from d-i
[17:35] <cjwatson> did something pick /dev/vda /dev/vdb /dev/vdc for you, or did you enter that yourself?
[17:35] <mathiaz> cjwatson: let me pull up the preseed
[17:37] <Keybuk> pitti: http://people.canonical.com/~scott/deroot.patchpatch
[17:37] <mathiaz> cjwatson: http://people.canonical.com/~mathiaz/raid5.preseed
[17:37] <Keybuk> pitti: does that smell/look right to you?
[17:38] <cjwatson> mathiaz: ok, bug on grub-installer I guess, then
[17:40] <cjwatson> all a bit odd, no idea where it gets /dev/vd[a-c] from there
[17:40] <cjwatson> a syslog with DEBCONF_DEBUG=developer might help
[17:41] <mathiaz> cjwatson: ok - I'll retry an installation
[17:41] <mathiaz> cjwatson: DEBCONF_DEBUG=developer should be set on the command line?
[17:41] <mathiaz> cjwatson: the *kernel* command line?
[17:41] <cjwatson> yes
[17:42] <mathiaz> cjwatson: ok - I'll respun an install a file a bug against grub-installer
[17:44] <Keybuk> pitti: actually, that won't work :-/
[17:44] <bryceh> geser, I use scripts to work on bugs in LP.  The scripts parse and use info from the .log and lspci.  So you don't have to provide that info, but it makes it less likely your bug will get attention.
[17:45] <cjwatson> mathiaz: thanks!
[17:46] <Keybuk> pitti: I guess seteuid(<arbitrary number>) would upset you?
[17:54] <pitti> Keybuk: re
[17:54] <Keybuk> pitti: so there's no way for the klog module to know the uid that syslogd is going to use
[17:55] <pitti> Keybuk: it shouldn't matter which uid it is, though
[17:55] <Keybuk> right
[17:55] <pitti> "nobody" (65534) shoudl be fine
[17:55] <Keybuk> so is there any random uid I can use that won't upset you? :p
[17:55] <Keybuk> ok
[17:55] <seb128> re
[17:55] <pitti> read() shouldn't check user at all
[17:55]  * seb128 shakes fist at plymouth which got installed back
[17:55] <pitti> Keybuk: so the patchpatch code runs under setuid()? or as root?
[17:55] <Keybuk> pitti: as root
[17:55] <seb128> and keeps crashing my box on user switch
[17:56] <pitti> Keybuk: ah, then wrapping into seteuid(65534)/read()/seteuid(0) ought to work
[17:56] <pitti> Keybuk: 1 is a static uid "daemon", that also seems appropriate
[17:56]  * pitti checks LSB
[17:57] <seb128> slangasek, Keybuk: I still get the "user switching lead to a cursor over a text vt taking over my xorg"
[17:57] <Keybuk> pitti: updated patch
[17:58] <seb128> slangasek, Keybuk: if you need debug infos or something feel free to ping me
[17:58]  * seb128 uninstall plymouth
[17:58] <pitti> Keybuk: right, "daemon" is required, but it doesn't prescribe uid 1; but it shouldn't matter
[17:58] <Keybuk> yeah, will just use 65534
[17:59] <pitti> Keybuk: looks okay to me (why don't you just use saved_errno in the LogIntMsg()?)
[17:59] <Keybuk> pitti: in case there are other reasons it gets used later I guess
[17:59] <Keybuk> like what that ksyslog() call does
[17:59] <pitti> ah, it's not a libc function, I see
[17:59] <pitti> looks fine to me; many thanks!
[18:04] <Keybuk> right
[18:04] <Keybuk> now to make quilt update the patch
[18:04] <Keybuk> quit --please --please --please --ill --do --whatever --you --ask --just --do --what --i --want
[18:04] <pitti> quilt push foo.patch
[18:05] <pitti> patch < patchpatch
[18:05] <pitti> quilt refresh
[18:05] <pitti> quilt pop -a
[18:05] <pitti> shoudl work
[18:05] <pitti> Keybuk: oh, please don't call "quit"! we still need you!
[18:06] <Keybuk> pitti: doesn't want to work
[18:06] <Keybuk> quilt refresh didn't do anything
[18:06] <Laney> quilt import?
[18:06] <slangasek> seb128: I'm in a holding pattern on plymouth; Keybuk tells me much of this should be getting fixed upstream
[18:06] <Laney> or quilt push blah; quilt shell; hack; exit; quilt refresh
[18:06] <pitti> "quilt shell"? that's news to me
[18:07] <Keybuk> Laney: so, the state I am currently in:
[18:07] <Keybuk> I have applied the quilt patches
[18:07] <slangasek> seb128: that particular bug may fall out from some of the other fixes for the boot-time problems everyone is seeing, so I'm not going to dig into it right now
[18:07] <Keybuk> I have modified the working tree
[18:07] <pitti> Keybuk: did "quilt push foo.patch" work?
[18:07] <Keybuk> now how do I get the working tree changes *back into the patch* ?
[18:07] <Laney> you have to quilt add the files you changed
[18:07] <Laney> then quilt refresh
[18:07] <pitti> "quilt refresh" ought to do that
[18:07] <Laney> (I think)
[18:07] <pitti> Laney: its' not adding new files
[18:07] <Keybuk> pitti: No patches in series
[18:07] <slangasek> Laney: if you've already modified them, it's too late to do a 'quilt add'
[18:07] <Laney> oh...
[18:07] <Keybuk> quest rsyslog-4.2.0% quilt refresh
[18:07] <Keybuk> Patch deroot.patch is unchanged
[18:07] <seb128> slangasek, ok, fair enough
[18:08] <Keybuk> FWIW, I did the "quilt add" in advance
[18:08] <Keybuk> it said
[18:08] <Keybuk> quest rsyslog-4.2.0% quilt add plugins/imklog/linux.c
[18:08] <Keybuk> File plugins/imklog/linux.c is already in patch deroot.patch
[18:08] <pitti> right, if you change an already patched file, you don't need to add it again
[18:08] <pitti> it's differently complicated than git :)
[18:08]  * ogra is happy to see that even Keybuk struggles with that user-unfriendlyness 
[18:08] <Laney> use quilt edit or quilt shell to be safe
[18:08] <ogra> i get beaten up all the time if i complain about it
[18:09] <Laney> it's knobbly and annoying
[18:09] <cjwatson> I don't beat people up for complaining about it - I just find all the alternatives worse in different ways :)
[18:09] <pitti> what is really (un)funny is to generate 99autoreconf with quilt
[18:09] <seb128> or not so
[18:09] <Laney> pitti: that's where you want quilt shell
[18:09] <ogra> cjwatson, so why dont we have quilt-edit-patch that does all the ugly stuff for me ?
[18:09] <pitti> indeed, I didn't know about quilt shell, that's handy
[18:09] <Keybuk> so
[18:09] <Keybuk> any ideas?
[18:09] <pitti> Laney: thanks
[18:09] <cjwatson> nowadays what I do is to work in bzr (doing a temporary bzr init .; bzr add if necessary) and then punt necessary stuff into quilt afterwards
[18:10] <cjwatson> ogra: mvo has been working on an edit-patch wrapper
[18:10] <Keybuk> stuff in working tree, patch on top
[18:10] <Keybuk> how do I make quilt update the patch?
[18:10] <ogra> cjwatson, oh, you just made my day !
[18:10] <pitti> Keybuk: quilt push deroot.patch; quilt shell; patch < patchpatch; exit 0 <- perhaps?
[18:10] <cjwatson> quilt shell does appear to be The Right Thing
[18:10] <cjwatson> it's basically what people complain about not having
[18:10] <slangasek> Keybuk: if you did the 'quilt add', then 'quilt refresh' should DTRT; it's not?
[18:11] <Keybuk> pitti: quilt push says "No patches in series"
[18:11] <pitti> push/refresh has usually worked for me as well, but perhaps there's some differnet assumption here which I'm not aware of
[18:11] <pitti> Keybuk: oh, hang on
[18:11] <Keybuk> slangasek: quilt add says "File plugins/imklog/linux.c is already in patch deroot.patch"
[18:11] <pitti> Keybuk: export QUILT_PATCHES=debian/patches
[18:11] <pitti> do you have that?
[18:11] <cjwatson> lp:~mvo/+junk/edit-patch
[18:11] <pitti> it defaults to ./patches
[18:11] <Keybuk> pitti: no?
[18:11] <pitti> I just set that in my .bashrc
[18:11] <cjwatson> may be worth using that - it includes all of the tips listed in this channel so far
[18:12] <pitti> Keybuk: check if it created a ./patches/deroot.patch; you might need to clean that up
[18:12] <Keybuk> pitti: it didn't create that
[18:12] <Keybuk> but setting that makes it work
[18:12] <cjwatson> http://paste.ubuntu.com/383162/ is the quilt bit of it
[18:12] <Keybuk> \o/
[18:12] <cjwatson> or was, he's updated it a little since I last looked
[18:13] <pitti> Keybuk: I have that in my .bashrc, since I only ever use it for debian/patches; everything upstreamish is bzr/git anyway
[18:13] <cjwatson> I picked up http://paste.ubuntu.com/383163/ in ~/.quiltrc from somewhere, and it generally DTRT
[18:14] <slangasek> "from somewhere" - that's in /usr/share/doc/quilt/README.source
[18:14] <slangasek> (which is hardly an obvious place for it)
[18:14] <cjwatson> seems plausible
[18:14] <Keybuk> cjwatson: ooh, handy thanks
[18:15] <cjwatson> for true horror, try slang2
[18:15] <Keybuk> slangasek: do you want this in the queue/archive?
[18:15] <cjwatson> dpkg-source v3 *and* dbs
[18:15] <slangasek> Keybuk: "this"?
[18:15] <pitti> boggle
[18:15] <Keybuk> slangasek: rsyslog
[18:15] <pitti> cjwatson: tar-in-tar?
[18:16] <cjwatson> yep
[18:16] <Keybuk> "I can put it anywhere"
[18:16] <slangasek> Keybuk: sorry, my current context was truncated somewhere in the midst of quilt discussions :-)  yes, please upload rsyslog to the archive
[18:16] <Keybuk> cjwatson: YADA
[18:16] <cjwatson> and the change was together with a new upstream release, so there isn't even the excuse of not wanting to rev the .orig.tar.gz
[18:16] <slangasek> heh
[18:19] <slangasek> Keybuk: yada.m4
[18:20] <seb128> slangasek, can I upload a libgnome-keyring fix?
[18:20] <seb128> slangasek, http://git.gnome.org/browse/libgnome-keyring/commit/?id=5e37e8cc09712fd8cab60e42636f260f23bacd7e
[18:20] <Keybuk> rsyslog is a bit crazy
[18:20] <seb128> slangasek, basically right now gnome-keyring doesn't ask the "do you want to create a keyring" if there is none
[18:21] <Keybuk> it's like someone looked at syslogd and thought "what this *really* needs is a plugin architecture"
[18:21] <seb128> slangasek, which makes desktopcouch crash because it can't use gnome-keyring
[18:21] <seb128> slangasek, and probably cause some other issues on new installs
[18:23] <ogra> seb128, oh, wait
[18:23] <slangasek> seb128: you can upload, but I'm not thinking this should be cause for a respin
[18:23] <seb128> ogra: it's in libgnome-keyring, not gnome-keyring, ie not what ftbfs for you
[18:23] <ogra> bug 527179 should have a gnome-keyring debdiff too
[18:23] <slangasek> seb128: once the user upgrades libgnome-keyring after install, they should get correct behavior, yes?
[18:23] <seb128> slangasek, yes
[18:24] <ogra> seb128, hmm, i thought they FTBFS both
[18:24] <seb128> slangasek, I don't think it's worth an alpha respin
[18:24] <slangasek> seb128: yep - so we should push to the archive but not respin
[18:24] <seb128> ogra: I will look at this too
[18:24] <ogra> seb128, thanks
[18:24] <seb128> slangasek, thanks, I was just checking if upload was ok or would create issues with current respins
[18:24] <seb128> ogra: np
[18:24] <ogra> :)
[18:26] <slangasek> ogra: why hasn't anyone from your team uploaded the gnome-keyring change before now, when the fix has been known for > 24h?
[18:26] <ogra> slangasek, look when the bug was filed, NCommander has connection issues after he wrote the fix
[18:26] <ogra> *had
[18:27] <ccheney> mvo: ping
[18:28] <ccheney> mvo: are echo's from install scripts somehow supressed in the DpkgTerminalLog.txt?
[18:29] <slangasek> ogra: bug, yes; but the fix was discussed in #ubuntu-release 24h ago as I said, it's not clear to me why this should have waited for NCommander to file a bug report again
[18:30] <ogra> slangasek, he said he would provide me a debdiff so i was waiting ... then he vanished from the sufrface of the earth until some hours ago, because i didnt expect that we still could upload and pitti was in the last rounds of respins already i asked him to file the bug so the fix doesnt get lost
[18:31] <mvo> ccheney: they shouldn't be - do you have a example where it does not work?
[18:31] <ogra> slacker_nl, i'll do the upload after the freeze unless seb128 has picked it up by then
[18:31] <ogra> err
[18:31] <ogra> slangasek, ^^
[18:31] <slangasek> tseliot: linking bug #526892 to foundations-lucid-boot-experience in place of the corresponding whiteboard item, as long as people are filing bugs we might as well use them :)
[18:31] <ccheney> mvo: i'm not sure if it is working for openoffice.org-emailmerge.preinst
[18:32] <ccheney> mvo: i am still getting weird errors from users like http://launchpadlibrarian.net/39732587/DpkgTerminalLog.txt
[18:32] <mvo> ccheney: ok, let me have a look
[18:33] <mvo> ccheney: what is the bug accociated with it?
[18:33] <ccheney> bug 527168
[18:33] <mvo> ccheney: hm, emailmerge - that rings another bell (a history of maintainer script problems :(
[18:33] <tseliot> slangasek: right ;)
[18:34] <ccheney> mvo: yea i backported the current preinst fixes and it still does the same type error
[18:35] <slangasek> ogra: ubiquity was a 2h17 build, gnome-keyring is ~30min; had this been uploaded in parallel at any point, you would have the up-to-date gnome-keyring on the next ISO. <shrug>
[18:35] <ogra> well ...
[18:35] <mvo> ccheney: from looking at the current preinst exit 1 is also done after the debconf prompt, no prompting then (in current lucid)
[18:35] <mvo> ccheney: you will see nothing in the terminal when users use gnome debconf (the default in u-m)
[18:36] <ccheney> ubuntu-mobile?
[18:36] <mvo> ccheney: update-manager, sorry
[18:36] <ccheney> oh ok :)
[18:36] <ccheney> so we do display debconf messages?
[18:37] <mvo> ccheney: is there a way to make OOo exit (and save work)? then you could make the default debconf action to send graceful-kill
[18:37] <mvo> ccheney: yes, via the gnome frontend by default
[18:37] <ccheney> oh ok
[18:37] <mvo> unless people upgrade explicitely with non-interactive
[18:37] <mvo> (which is not default and not something we encourage)
[18:38] <ccheney> yea in non-interactive case it should be logging though, so i think they are just ignoring the message and filing a bug :-\
[18:38] <mvo> something like "You are running OOo, we can close it for you"
[18:38] <mvo> right
[18:38] <mvo> the default action should therefore (if that is possible) to kill OOo and make it write a recover file. and if people do not like it they can select a different debconf option
[18:38] <ccheney> mvo: not sure if there is a way to cause it to shutdown
[18:38] <mvo> (and complain)
[18:38] <mvo> kill -9 :P
[18:38] <mvo> (not really)
[18:39] <ccheney> well if we kill it leaves the lockfile which i think it might be using to do the recover bit
[18:40] <mvo> you could of course simply add a "echo user closed, but OOo still running" and create a bug pattern that auto-closes these reports
[18:40] <ccheney> yea
[18:41] <ccheney> i think i will add that
[18:41] <mvo> I personally think the default for any debconf question during a upgrade should be "continue in some sensible way"
[18:41] <mvo> and not "fail"
[18:41] <mvo> but I know that its not always possible (especially for server packages)
[18:41] <jml> is there a schedule for lucid+1 somewhere?
[18:41] <ccheney> yea :-\
[18:41] <jml> we're looking at shifting Twisted to releasing every three months and we want to be in sync w/ Ubuntu
[18:42] <jml> (we missed the feature freeze for lucid, unfortunately)
[18:42] <ccheney> jml: well the release date is very likely to be Oct 28, but it doesn't seem to have a release schedule yet
[18:45] <jml> ccheney, feature freeze is what I care about the most, I guess.
[18:45] <jml> ccheney, maybe I can make a guess based on karmic's schedule
[18:45] <ccheney> jml: yea probably will be about the same as jaunty/karmic
[18:47] <ccheney> hmm did the wiki go down?
[18:47] <ccheney> my ff is just sitting waiting for response
[18:48] <ccheney> working now, hmm
[18:49] <ccheney> jml: guesstimate would be final freeze on aug 26
[18:51] <jml> ccheney, ok, thanks.
[18:52] <tkamppeter> pitti, hi
[19:01] <mpt_> asac, are you able to answer Joanmarie's question in <http://launchpad.net/bugs/433104>: "what is the cut-off point for Ubuntu including a newer release of WebKitGtk?"
[19:19] <asac> mpt_: the cut off point was FF ... everything on top needs careful review and approval
[19:20] <asac> is there anything upstream yet for that?
[19:21] <asac> answered in bug
[19:23] <mpt_> asac, ok, thanks for the answer
[19:23] <asac> np
[19:24] <alex-weej> is there some reason rpm/alien is now a dependency of my karmic install? or is it some dodgy package upgrade i have?
[19:26] <slangasek> alex-weej: rpm is a dependency of lsb-core, so if you have any of the lsb support installed that would do it
[19:26] <alex-weej> my karmic install is many months old -- why is it being brought in now?
[19:27] <slangasek> dunno, would have to see an upgrade log to tell you
[19:29] <mpt> asac, incidentally, it's kind of weird that <https://launchpad.net/webkit> (a) talks about WebKit being an "attempt" and (b) has, as its latest download, a Firefox variant
[19:31] <asac> mpt: i am hopefully not the owner of the webkit launchpad project ;) ... am i?
[19:33] <mpt> asac, true, but it also shows up on https://launchpad.net/ubuntu/+source/webkit
[19:39] <cjwatson> jml: yes, add a year to karmic's schedule and you'll be within a week or two of m's
[19:44] <alex-weej> question: i'm very interested in doing some system testing, especially regression testing between releases. is there a formal team that i can join?
[19:44] <alex-weej> ideally i want to make sure a wide range of macs are included in testing
[19:45] <alex-weej> as many of my friends are quite upset with regressions etc.
[19:46] <ion> Dunno if this idea is insane, but anyhoo, bug #527292. :-)
[20:18] <jcole> is it possible to have the "guest" session start in an xnest by default?
[20:19] <slangasek> alex-weej: I think that's in scope for https://wiki.ubuntu.com/Testing
[20:19] <alex-weej> is there an official set of test hardware that canonical uses btw?
[20:20] <slangasek> ion: I'm kinda leaning toward 'insane', yes; sendmail is specified in the LSB with the expectation that *it can be used to send mail*, if it should be made optional then that should be done in the LSB instead of bodging it in the distro
[20:22]  * jcole pokes at files in gdm-guest-session
[20:23] <ion> slangasek: True. But on that basis, shouldn’t the package itself have never been added to Ubuntu in the first place?
[20:24] <slangasek> ion: ugh, that's an Ubuntu-specific add-on?
[20:25] <slangasek> pitti: you seem to have sponsored this; why do you think this is reasonable?
[20:25] <ion> slangasek: It seems to be, judging from the package’s changelog.
[20:26] <ion> FWIW, i’m happy a package like it appeared in Ubuntu. Things no longer want me to install a MTA to my desktop boxes. :-P
[20:27] <slangasek> ion: install ssmtp instead of a full MTA?
[20:30] <ion> slangasek: It expects me to have constant access to a certain forwarder. Doesn’t really work for my laptop. I rather just have no sendmail or a have sendmail binary that just fails.
[20:31] <slangasek> packages depend on an mta when they rely on being able to use /usr/sbin/sendmail to deliver messages to the system admin.  I care not one whit if that gets delivered to a local mailbox, or sent over SMTP, or delivered over *twitter* if that's what you want, but deliberately dropping them on the floor is wrong
[20:34] <ion> I didn’t mean packages that depend on an MTA, but packages that recommend one. I want my apt-listchanges just to show the changes, not mail them. I wouldn’t need mdadm’s email functionality on a hypothetical desktop box with RAID.
[20:45] <lamalex> Does anyone know how to debug debootstrap/cowbuilder/pbuilder?
[20:45] <lamalex> it's dying with a very generic error
[20:46] <lamalex> http://paste2.org/p/687241
[20:50] <jcole> lamalex: are you running it with sudo
[20:51] <lamalex> jcole: no, but I don't need to when I do cowbuilder-dist <ubuntu release> create
[20:51] <lamalex> it works fine then
[20:52] <lamalex> but I'm trying to set up cowbuilder to work off of a different distro
[20:56] <geser> cowbuilder-dist might call cowbuilder with sudo (check the source)
[20:57] <geser> and you need to "sudo cowbuilder" if you don't use "cowbuilder-dist"
[20:58] <lamalex> geser: it does
[20:58] <lamalex> i should have said that,sorry :P
[20:58] <lamalex> i think the problem is an incomplete mirror
[22:19] <qense> I'm working on giving Guake AppIndicator support and I would like to include something like C's preprocessors in the code to allow people to not use AppIndicator. Does anyone know how to do such a thing? The project is using a makefile and not something like python-distutils.
[22:21] <seb128> qense, the code is python?
[22:21] <qense> seb128: yes, so preprocessors won't do the trick
[22:22] <seb128> qense, well at runtime should work then
[22:22] <seb128> look at jockey
[22:22] <seb128> just try: the import
[22:22] <seb128> no?
[22:22] <qense> seb128: thank you! I'll have a look at jockey.
[22:49] <Caesar> What package provides the system status info in /etc/motd on Ubuntu Server?
[22:50] <jpds> Caesar: update-motd?
[22:50] <Caesar> jpds: thanks
[22:50] <ccheney> update-motd claims that libpam-modules does it now
[23:07] <jcole> is there an irc room for the ubiquity ubuntu installer
[23:07] <lifeless> here usually, I think
[23:07] <stgraber> jcole: ubuntu-installer
[23:08] <jcole> perfect, thanks