[00:37] <ScottK> cjwatson: Are you sponsoring libnet-server-perl?
[00:43] <cjwatson> ScottK: yes, just did
[00:43] <ScottK> OK.  Thanks.
[00:44] <cjwatson> glad somebody dealt with that, it was in danger of languishing on my queue
[00:45] <_min_> join #ubuntu
[00:50] <slangasek> broder: bug #854329, fwiw
[00:52] <ScottK> If Firefox is so embarrassed about having crashed, why does it keep doing it ...
[00:53] <lifeless> slow learner
[02:07] <Lirodon> so I'm randomly throwing out ideas for making the boot process a little more elegant
[02:09] <RAOF> It's worth noting that ideas are generally cheap; it's the implementation that's generally hard, and we've got lots of implementin' to do already.
[02:10] <Lirodon> http://i.imgur.com/EH2AH.png how hard would it be to rig something like this up in GRUB 2?
[02:11] <RAOF> I've not played with GRUB's theming myself, but from what I've seen of others' theming that looks perfectly doable.
[02:11] <Lirodon> Yeah, for something that simple, I've seen WAY more complex things in gfxmenu
[02:19] <Lirodon> I had another wayward plot of having Ubuntu converted into a console font
[02:31] <ScottK> It's a little late in the release cycle for new ideas too.  We're mostly on "OMG - Broken" stuff now.
[02:32] <Lirodon> well, for the next one
[02:32] <RAOF> Eh.  It's the perfect time for ?I'd like to do some feature-work for the next cycle? though.
[02:33] <jbicha> I'd like to see memtest & recovery hidden behind the second screen where the older kernels live
[02:33] <Lirodon> Did they at least give us the right to change our GTK theme/window border/stuff? in Unity?
[02:34] <jbicha> since so many normal users dual boot, having a cleaner grub is useful
[02:34] <jbicha> Lirodon: yes, you can switch between Ambiance & Radiance in System Settings>Appearance, if you want more try gnome-tweak-tool
[02:35] <Lirodon> Oh that is just a downgrade
[02:36] <Lirodon> least its better than nothing at all *cough Gnome 3*
[04:15] <pitti> Good morning
[04:33] <pitti> bdmurray: do you mind if I reject the kerneloops upload? we certainly want to keep it enabled until release
[05:31] <didrocks> good morning
[06:49] <tkamppeter> pitti, hi
[06:51] <pitti> hello tkamppeter
[06:54] <tkamppeter> pitti, it is about bug 853921. Do you know why our CUPS depends on ttf-freefont? According to an upstream bug report the original source does not depend on this package.
[06:55] <pitti> tkamppeter: it was you :) in 1.3.8-4
[06:55] <pitti> Added "Depends: ttf-freefont" for the cups package, as the
[06:55] <pitti>     texttopdf filter needs these fonts.
[06:59] <tkamppeter> pitti, so it seems that I have to ask the author of the texttopdf filter whether there are alternatives (or simply uninstall ttf-freefont and see whether the filter keeps working).
[07:02] <dholbach> good morning
[07:07] <apw> slangasek, wass'up
[07:07] <slangasek> apw: hiya
[07:08] <apw> slangasek, i see my name in scrollback... any details on the problem?  (you were talking to master watson)
[07:22] <slangasek> apw: right, I get a black text screen w/ cursor still in between grub and plymouth; and it's not the hwmatch issue anymore
[07:23] <slangasek> apw: I can't offer much more than that currently, except to say that plymouth starts from my initramfs and I'm looking to see if I can rule that out as a cause
[07:23] <apw> slangasek, i presume you've forced keep to confirm that in the specific grub entry for boot
[07:23] <apw> slangasek, as if the previous boot was a fail you get =text regardless of hwmatch
[07:23] <slangasek> sorry, done what?
[07:24] <apw> if you edit the entry it has gfxpayload=$something in it, change that to =keep to be really sure we are handing off
[07:24] <apw> as grub2 can turn off handling for reasons other than your h/w components.  previous failure to boot being one of them
[07:25] <slangasek> ah; well, it's happened on every single boot, so unless grub is confused about what constitutes a boot failure it wouldn't seem to be that
[07:25] <slangasek> but I can test with a forced 'keep', sure
[07:25] <apw> slangasek, that'd be great as i wasted 2 days debugging one of mine to find it was doing that to me :/
[07:26] <slangasek> yeesh
[07:26] <slangasek> where does recordfail get recorded?
[07:27] <apw> slangasek, it occurs to me we could do with some kind of debug mode here so we can tell who is making these black screens... perhaps by making themm all different colours
[07:27] <apw> slangasek, now that i don't know
[07:39] <tkamppeter> pitti, for getting CUPS independent of ttf-freefont I need to copy 4 font files from ttf-freefont into cups. It is around 900K. Is this OK?
[07:40] <pitti> tkamppeter: no, why? we can just keep the dependency
[07:41] <pitti> the point of that bug was to get rid of the need for it, not to copy the files around to all places which still need it -- in that case we should just keep the package around
[07:56] <tkamppeter> pitti, how should we handle this bug then?
[07:59] <pitti> tkamppeter: I'd just keep it as it is, and use it to track removing the dependency from texttopdf
[08:00] <pitti> tkamppeter: at one point we had an alternative depends on gsfonts-x11 or something like htat
[08:01] <tkamppeter> pitti, so we should better do changes inside texttopdf? Has this to be done for Oneiric or is this for the longer term?
[08:02] <pitti> tkamppeter: this bug is in no way urgent
[08:03] <tkamppeter> pitti, OK, so it is for P. P. ...
[08:04] <tkamppeter> pitti, bug 853133 gives the impression that some icon got taken out of Oneiric which is needed by system-config-printer. What to do in such a case?
[08:07] <pitti> tkamppeter: hm, it's shipped in humanity-icon-theme
[08:07] <pitti> so it should be there by default
[08:10] <seb128> pitti, if people use humanity...
[08:10] <tkamppeter> pitti, thanks, so I will ask the reporter of this bug to reinstall humanity-icon-theme.
[08:10] <seb128> tkamppeter, you can ask what icon theme they use as well
[08:10] <seb128> it's likely they use a different one
[08:18] <tkamppeter> seb128, I have asked. Please also add a comment to the bug if you have better ideas how to ask the user for the needed info.
[08:27] <mvo> tkamppeter: good morning! when testing a release upgrade in a vm I get a hang when cups is restarted early, it appears like its starting up but then terminates really quickly (status 27 is what syslog tells me). any idea how to debug this further?
[08:32] <tkamppeter> mvo, can you set CUPS to debug logging ("cupsctl LogLevel=debug") and restart CUPS again? Can you also have a look into bug 854490? This seems to be something similar.
[08:33] <tkamppeter> pitti, it seems that there is a problem with CUPS and Upstart, can you have a look into bug 854490? mvo seems to have the problem, too.
[08:34] <tkamppeter> mvo, when the error occurs again, have a look into /etc/cups/cupsd.conf.
[08:34] <tkamppeter> mvo, as usual, I am scrambling up everything. Trying again ...
[08:35] <pitti> tkamppeter: it's not an upstart issue
[08:35] <tkamppeter> mvo, ... when the problem occurs again, can you have a look into /var/log/cups/error_log?
[08:35] <pitti> either the daemon is crashing or hanging, or the post-start script which does the PPD updates, and all the coldplugging is hanging
[08:35] <pitti> we need error_log
[08:36] <pitti> and possibly a set -x in the post-start script to see what's gong on
[08:36] <mvo> tkamppeter: thanks, that is very helpful, I will re-run the test with the debug on
[08:36] <pitti> 'going'
[08:36] <mvo> tkamppeter, pitti: cups keeps crashing and init keeps restarting it, that is what i see in syslog
[08:37] <tkamppeter> mvo, so the /usr/sbin/cupsd crashes? So then we need the error_log, perhaps better in extended debug mode ("cupsctl LogLevel=debug2").
[08:39] <mvo> that is what I saw in the log, I restartedthe upgrade test, will take a couple of minutes until I hit the bug again
[08:39] <tkamppeter> mvo, cups crashes with exit status 27 or 127?
[08:41] <tkamppeter> mvo, if you do not get the "cupsctl" command to work due to no running CUPS daemon, edit /etc/cups/cupsd.conf, making sure it contains a line "LogLevel debug2" and no other LogLevel line.
[08:42] <mvo> tkamppeter: 127
[08:42] <mvo> tkamppeter: thanks, I added it to the level, its running now, we just need to be patient now
[08:47] <mvo> tkamppeter: cupsd reports a missing symbol "_cups_strncasecmp" - I will attach the full log to the bugreport
[08:50] <mvo> tkamppeter: updated with the full info
[08:56] <tkamppeter> mvo, this look like the CUPS library and the CUPS daemon being updated in the wrong order, the daemon being restarted with a non-matching CUPS library being present.
[08:59] <mvo> tkamppeter: right, at this point libcupsmime1 is unpacked but not configured yet
[09:01] <tkamppeter> pitti, about the problem of mvo, how is the best way to assure that the restart of cupsd only happens if all libraries needed by cupsd are completely updated? Is the "Depends: ${shlibs:Depends}" in debian/control not enough?
[09:01] <pitti> tkamppeter: which library is behind in particular? it already depends on >= 1.5.0 for libcups2 and libcupsmime1
[09:02] <pitti> tkamppeter: but it only has >= 1.4 depends for libcupscgi1, libcupsdriver1, libcupsimage2, libcupsppdc1
[09:02] <pitti> tkamppeter: these are determined using the symbols files, but I just recently fixed a bug in Debian which had a too weak libcupsmime1 dependency
[09:02] <pitti> as cupsd was using private symbols from that library
[09:03] <tkamppeter> pitti, the symbol is _cups_strncasecmp, looks like a private symbol, but I do not know which library provides it.
[09:04] <pitti> sounds like debian bug 641182
[09:05] <tkamppeter> pitti, did you actually upload 1.5.0-6? In the BZR it is marked unreleased?
[09:06] <pitti> I did, yes, and it's released in bzr (r1044)
[09:06] <pitti> but it might very well be another library which is lagging behind
[09:06] <pitti> I only bumped the dependency to libcupsmime1
[09:08] <tkamppeter> pitti, perhaps you should bump the dependencies of all libraries, due to the problem of private symbols being used.
[09:08] <Sp4rKy> W8
[09:10] <pitti> tkamppeter: yeah, possibly
[09:11] <pitti> tkamppeter: ah, mvo said it was libcupsmime1
[09:11] <pitti> mvo: cups has a Depends: libcupsmime1 (>= 1.5.0-0ubuntu1), how can libcupsmime1 not be configured yet when cups gets configured?
[09:12] <pitti> mvo: the symbols didn't change between -0ubuntu1 and -6
[09:12] <pitti> I still don't understand this bug at all
[09:12] <pitti> if libcupsmime1 1.4.0 was still installed, then this can happen
[09:12] <tkamppeter> pitti, for me it looks like that libcupsmime uses the symbol _cups_strncasecmp which is provided by another CUPS library. This other CUPS library seems not to be up-to-date.
[09:13] <pitti> that's from libcups2
[09:13] <mvo> pitti: cups does not get configured at this point, its libpam0g triggering the restart
[09:13] <pitti> but libcupsmime1 has Depends: libcups2 (>= 1.5~), so sohuld be fine
[09:13] <pitti> mvo: oh
[09:13] <pitti> that can't work
[09:13] <pitti> as that could happen at any time, and we can't enforce any ordering there with depends?
[09:14] <mvo> its pretty unfortunate timming, cups is unpacked, libcupsmime1 is unpacked, but both are not configured yet
[09:14] <mvo> pitti: tricky, I guess we could try something with versionized breaks in libpam0g
[09:15] <pitti> mvo: is cupsd actually running at that time?
[09:15] <pitti> IMHO libpam0g's postinst shouldn't start services which aren't running
[09:15] <pitti> as that's bound to fail, not only for cups
[09:16] <pitti> AFAICS /var/lib/dpkg/info/libpam0g:amd64.postinst makes no attempt to determine if a service is running, except for gdm
[09:16] <mvo> pitti: I don't know, I can check in a bit when triggering the next upgrade
[09:20] <pitti> mvo, tkamppeter: bug updated
[09:22] <tkamppeter> pitti, OK, thanks.
[10:27]  * jml discovers libapr1.symbols
[10:40] <Sweetshark> if someone knowing his way around ecryptfs could have a look at bug 745836 and see if he/she could drop a hint or give a clue that would be most helpful.
[11:00] <tkamppeter> What does "package libgs9 9.04~dfsg-0ubuntu7 failed to install/upgrade: short read on buffer copy for backend dpkg-deb during `./usr/lib/libgs.so.9.04'" mean? Is this a problem of the packaging, the user's system, or the mirror?
[11:01] <geser> IIRC there was a blog about it, let me find it
[11:03] <geser> tkamppeter: http://raphaelhertzog.com/2011/06/27/deciphering-one-of-dpkgs-weirdest-errors-short-read-on-buffer-copy/
[11:03] <tkamppeter> geser, thanks.
[11:21] <doko> ScottK, webkitkde ping, bug 832933
[11:22] <doko> soren, ping on bug 836997
[11:42] <soren> doko: I've not forgotten about it, but also haven't had a chance to look at it at all yet.
[11:42] <ivoks> sta si kupio? :)
[11:43] <soren> ivoks: *blink*
[11:43] <ivoks> :)
[11:43] <ivoks> wrong channel
[11:43] <soren> :)
[11:48]  * Sweetshark wonders if he can get below 800 open bugs in LO-packaging before release ..
[11:49] <pitti> Sweetshark: you know, we have an API to close bugs :)
[11:52] <Sweetshark> pitti: doesnt help really if I need to read them ...
[11:52] <Sweetshark> pitti: ... or should I skip that? ;D
[13:05] <ScottK> doko: Done.
[13:05] <doko> ScottK, and my pings about dovecot-* ?
[13:06] <ScottK> doko: You didn't get my ping back to ask Daviey?
[13:06] <doko> sorry, no
[13:06] <ScottK> Him or ivoks.
[13:06] <ScottK> No problem.
[13:07] <ScottK> doko: BTW, the only solution I see for bug 836830 is binary removal since the needed build-dep isn't even packaged in Debian.
[13:08] <doko> binary+source
[13:08] <ScottK> Doesn't hurt to leave the source for once it's fixed.
[13:08] <ScottK> There's an ITP for the missing depends, so presumably it'll get sorted eventually.
[13:09] <ScottK> Either way, but don't blacklist it.
[13:37] <shnatsel> infinity: hello, I seek docs about live-build :) They are needed for UGR, elementary OS and local seed/ISO testing Ubuntu Studio. There seems to be a comprehensive guide at http://live.debian.net/manual/, but according to https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-live-build ubuntu did a lot of tweaks, so first of all I need a tutorial to reproducing Ubuntu images.
[13:42] <ogra_> shnatsel, have a look at livecd-rootfs
[13:42] <ogra_> it has all the ubuntu related additions
[13:43] <shnatsel> ogra_: the blueprint says that it's abandoned and ISO builds are switched to live-build since Oneiric
[13:43] <ogra_> it was implemented differently
[13:44] <ogra_> all ubuntu realted bits that require non-upstream suitable changes are in livecd-rootfs ... everything else went upstream into live-build
[13:45] <shnatsel> ogra_: ah-hah... so, how do I reproduce an Ubuntu ISO using these tools?
[13:45] <ogra_> not at all, live-build produces livefs images
[13:45] <ogra_> no isos
[13:46] <ogra_> you would get a kernel, initrd and squashfs out of it ...
[13:46] <ogra_> (on x86 at least)
[13:46] <shnatsel> let's assume I'm familiar with it
[13:46] <shnatsel> so, how do I reproduce the squashfs image then?
[13:47] <shnatsel> ah, wait, livefs
[13:48] <shnatsel> so I just have to pack it into ISO then, right?
[13:48] <ogra_> you will have to do some isolinux/syslinux stuff to make it bootable, but yes
[13:48] <shnatsel> and I can add stuff like wubi etc
[13:48] <shnatsel> ah-hah
[13:48] <dholbach> pitti, is there a new pango1.0 upload planed?
[13:48] <dholbach> planned
[13:49] <pitti> dholbach: I did one a few hours ago, a new upstream snapshot
[13:49] <dholbach> ah
[13:49] <pitti> dholbach: I haven't planned another one, but of course I can do one if you need something changed
[13:50] <dholbach> no, I was just wondering because gtimelog was not installable
[13:50] <dholbach> and I couldn't see a pango1.0 upload on oneiric-changes
[13:50] <dholbach> :)
[13:50] <doko> how do I make scons builds verbose by default?
[13:50] <shnatsel> ogra_: so, are there any docs on using live-build, livecd-rootfs or whatever?
[13:50] <ogra_> i dont think there is anything beyond the upstream documentation
[13:50] <ogra_> but that should suffice
[13:51] <shnatsel> upstream has never used live-build, ever
[13:51] <shnatsel> and I don't even know where to get ubuntu code
[13:52] <shnatsel> ooops
[13:52] <shnatsel> mistake
[13:52] <ogra_> you pointed to the upstream doc above
[13:52] <shnatsel> ugh... so many confusing names...
[13:53] <shnatsel> ogra_: yes but I still don't know where are the ubuntu tweaks, how do I get them etc
[13:53] <ogra_> in livecd-rootfs
[13:53] <shnatsel> upstream has never used livecd-rootfs, ever
[13:53] <ogra_> there is a live-build subdir
[13:53] <ogra_> that carries the additional scripts to put into the live-build tree
[13:54] <shnatsel> ah-hah... thanks
[14:01] <shnatsel> ogra_: so, shall I approach building ISOs using live-build directly or shall I use livecd-rootfs as a wrapper to live-build?
[14:02] <ogra_> what we do is using BuildLiveCD from livecd-rootfs though thats adapted to the build inbfarstructure in the datacenter
[14:04] <shnatsel> ogra_: and what are its requirements?
[14:08]  * shnatsel expects something like write access to ubuntu archive mirror
[14:11] <shnatsel> ugh... sorry g2g
[14:13] <bdmurray> pitti: I was coordinating the kerneloops work with the kernel team so check with them.
[14:39] <alexbligh> We are using the debian/ubuntu installer to install a custom version of Ubuntu Lucid from DVD. We have a working preseed file, but we need to ask the user a slightly complex question. We want to retrieve a list of options using curl, present them with the list of options (numbered), and allow them to choose a number (and write the option text somewhere on disk). We can't see how to do this directly from the preinst. We can write some perl or so
[14:39] <alexbligh> mething to ask the question, but d-i and dpkg -i seem to fail when anything asks for user input other than through the debconf frontend. Any ideas on how we might do this?
[14:45] <happyaron> doko: can you please try to sync the new version of ns3? it builds fine on most archs of Debian now.
[14:45] <happyaron> ns3 3.12.1+dfsg1-2
[14:48] <cjwatson> alexbligh: you should use debconf
[14:49] <cjwatson> alexbligh: you can dynamically generate lists of choices and substitute them into a debconf template using db_subst
[14:49] <cjwatson> it would be from a config script not the preinst, probably
[15:31] <ahasenack> hi guys, can someone take a look and hopefully approve the following SRU updates that are sitting in the unapproved queue? smart for lucid, maverick and natty
[15:31] <ahasenack> and landscape-client for maverick and natty
[15:32] <doko> happyaron, still ftbfs
[15:38] <doko> Daviey, zul: ping on bug 756107
[15:38] <zul> doko: ill take care of it right now
[15:39] <Daviey> doko: Looking, can you use ~ubuntu-server for things like this?
[15:39] <Daviey> ah, zul is ON THE CASE.
[15:43] <happyaron> doko: OK, I see it's a DSO linking issue, will communicate with the maintainer.
[15:44] <doko> happyaron, thanks
[15:49] <wzssyqa> hi doko
[15:55] <happyaron> doko: wzssyqa is the maintainer, he'd like to talk to you. (sorry I have to go offline now)
[15:55] <bhm> Hep! I'm looking for a guide to maintain a deb-ppa for a project on launchpad. Any good suggestions out there?
[16:00] <dtchen> bhm: e.g., https://help.launchpad.net/Packaging/PPA
[16:01] <bhm> dtchen: thanks
[16:40] <bdmurray> slangasek: so bug 553745 still seems to be happening in bug 849414
[16:43] <slangasek> bdmurray: right, looks like it...
[17:07] <MouraPsy> Hello
[18:16] <smoser> sbeattie, around
[18:16] <sbeattie> smoser: yeah, what's up?
[18:16] <smoser> bug 854927.
[18:16] <smoser> you are last-touched openssl .
[18:17] <smoser> :-(
[18:18] <sbeattie> smoser: happy happy joy joy. I'll look, thanks.
[18:21] <hallyn> adam_g: actually i don't even need any lvm partitions to get what looks like a udev hang
[18:21] <hallyn> it takes a few tries, but not more than say 5
[18:21]  * hallyn starts instrumenting initramfs scripts
[18:21]  * hallyn wonders if 'udevadm control --exit' is waiting for an already-exited udev to exit.  Nah, that's be too obvious
[18:22] <adam_g> hallyn: are you just using a standard guied partition table?
[18:22] <adam_g> *guided
[18:22] <hallyn> adam_g: yup, /dev/vda1 is a primary partition, /dev/vda3 is logical partition (swap)
[18:23] <hallyn> adam_g: it's a vm created by vm-new in vm-tools, fwiw
[18:23] <hallyn> (or, maybe it isn't.  anyway no lvm)
[18:25] <smoser> hallyn, i thin its just the expected situation where udevadm control --exit is losing events.
[18:26] <adam_g> yeah. on exit on udevd.c: /* close sources of new events and discard buffered events */
[18:27] <mdeslaur> smoser: quick question: do you have ca-certificates installed?
[18:27] <sbeattie> smoser: I'm unable to reproduce the wget/curl failure's you're seeing.
[18:27] <smoser> mdeslaur, i do
[18:27] <sbeattie> meh, failures.
[18:27] <smoser> really?
[18:27] <mdeslaur> I can't reproduce either
[18:28] <sbeattie> really
[18:28] <smoser> i see them on both my local system and on a new ec2 instance and new canonicalStack instance
[18:28] <hallyn> adam_g: and I gather udevadm settle is deemed a hack bc between that call and the --exit we can still get new events?
[18:28] <smoser> sbeattie, mdeslaur so i can very trivially give you access to a system that shows issues
[18:29] <sbeattie> smoser: proxy in the way, perhaps?
[18:29] <smoser> very unlikely.
[18:29] <smoser> kirkland can also reproduce
[18:29] <smoser> and i dont *think* he routes his traffic through my basement.
[18:30] <adam_g> hallyn: yeah, it looks like thats the case. udev needs to have some option to --exit that will flush its queue
[18:30] <kirkland> sbeattie: i've verified it both on my home machine, and ec2
[18:30] <smoser> adam_g, well, its really quite silly that it would have any path to exit that would *not* flush its queue
[18:30] <smoser> why would you nicely ask a daemon to exit, and expect it to lose data
[18:30] <smoser> you can get that with kill -9
[18:31] <adam_g> smoser: i dont disagree
[18:32] <smoser> sbeattie, i only picked openssl because it seemed fairly recently updated.
[18:32] <sbeattie> smoser|kirkland: these are all oneiric? two different oneiric systems succeed locally
[18:32] <smoser> i could have picked wrong package entirely.
[18:32] <smoser> sbeattie, dist-upgraded oneiric as of last night ~ 2am i think locally.
[18:33] <adam_g> this is an interested note from udev upstream: http://www.spinics.net/lists/hotplug/msg04749.html
[18:33] <tyhicks> I can't reproduce the ssl bug, either
[18:36] <mdeslaur> I just updated a i386 chroot, and can reproduce it
[18:36] <tyhicks> mdeslaur: and the report is on i386
[18:36] <tyhicks> I'm on amd64
[18:36] <tyhicks> and can't reproduce it
[18:37] <sbeattie> yeah, my systems are amd64
[18:37]  * sbeattie hrms
[18:37] <sbeattie> kirkland: are you on i386?
[18:37]  * micahg doesn't see the issue
[18:38] <mdeslaur> oh, d'uh, I didn't have ca-certificates installed
[18:38] <sbeattie> mdeslaur: heh, that would be a problem
[18:39] <micahg> maybe wget should suggest or recommend ca-certificates
[18:39] <mdeslaur> ok, still have the problem
[18:42]  * sbeattie wonders what's causing all the skipping duplicate certs message on install of ca-certificates.
[18:43] <kirkland> sbeattie: amd64
[18:43] <micahg> mdeslaur: I get the same error before the openssl upgrade w/out ca-certificates, with ca-certificated with 1.0.0d and 1.0.0e, no issue (i386)
[18:46] <mdeslaur> I can reproduce in my amd64 chroot also
[18:46] <sbeattie> weird, I see it in my i386 chroot.
[18:47] <sbeattie> well, I see the failure with curl + launchpad, wget against google works fine in my chroot
[18:48] <micahg>  ah, didn't try the second case
[18:49] <micahg> I get no curl error either
[18:50] <mdeslaur> this looks very wrong: lrwxrwxrwx 1 root root     19 Sep 20 14:38 415660c1.0 -> ca-certificates.crt
[18:53] <mdeslaur> I think ca-certificates is borked...it's linking all the cert files to ca-certificates.crt
[18:55] <hallyn> adam_g: looking at the code trying ot think how to structure a reliable --settle-and-exit
[18:55] <sbeattie> mdeslaur: ah, yeah, where things work, it's not like that.
[18:55] <hallyn> not entirely sure it's possible
[18:56] <sbeattie> smoser|kirkland: are you seeing this on systems that were installed recently or were upgrades?
[19:03] <mdeslaur> sbeattie: frack...installing ca-certificates with the old openssl works
[19:05] <Laney> it's been debugged in #-release, guys :-)
[19:05] <adam_g> hallyn: its been a while since i looked, but i was thinking it should be possible to duplicate 'udevadm control settle' in the daemon, between closing its netlink sockets and exitting
[19:08] <mdeslaur> Laney: thanks
[19:14] <hallyn> adam_g: what exactly is getting lost though?  inotify events?  or kernel uevents?  If the latter, are those async?  If so then yes we can just close the kernel uevent socket, process our queue, and exit.
[19:14] <hallyn> But if not, then there may not be a good way to make the events pile up while we are exited
[19:17] <hallyn> oh, what, init fwds them over inotify to udev?
[19:29] <hallyn> finally, there it is :)  udev_monitor_new_from_netlink_fd(udev, "kernel", fd_netlink);
[19:30] <hallyn> (or rather, the non-sd version of course)
[19:38] <adam_g> hallyn: sorry, ive been otp
[19:39] <hallyn> adam_g: np, i'm just blabbing
[19:39] <hallyn> adam_g: starting to get a feel for the code.  but trying to figure out exactly waht is magic during the 'udev_exit = 1'
[19:40] <hallyn> adam_g: in fact, the code looks like it thinks it's waiting for both events and workers lists to be 0 before really exiting,
[19:41] <hallyn> it stops taking ctrl msgs (from udevadm), that's sensible.  stops taking inotify - that may be our prolbem.  (it still takes netlink msgs from kernel, but since it will wait for any newly spawned workers to finish, that should be fine)
[19:41] <hallyn> maybe it'll do better if we keep accepting inotify events while we're waiting
[19:43] <adam_g> hallyn: what triggers inotify events? new nodes in /dev?
[19:44] <hallyn> that's been my assumption.  I've not dug deep enough to know the full list
[19:45]  * hallyn feels woefully under-informed at this point
[19:47] <hallyn> didn't we used to have a uevent_helper during initramfs?
[19:48] <hallyn> (guess not)
[19:49] <hallyn> adam_g: well the kernel object uevents are broadcast.  So if that is waht we're losing, then settle before exit won't help :)
[19:49] <hallyn> so, let me try just allowing inotify events while we're exiting.  stab in the dark, unlikely to help
[19:58] <slangasek> SpamapS: so I think we should talk about bug #848823
[19:58] <slangasek> SpamapS: since I'm about to volley it back over to ifupdown where it belongs :)
[19:58] <SpamapS> slangasek: on a call, in a bit?
[19:59] <slangasek> ok
[20:10] <SpamapS> slangasek: ok, so, what the problem is? :)
[20:10] <slangasek> SpamapS: hey, sent a follow-up comment to the bug, but in summary, it has nothing to do with what interfaces it's listening on, it's about not being able to resolve the hostnames listed in /etc/exports and therefore discarding the entries
[20:11] <SpamapS> slangasek: *OH*
[20:11] <SpamapS> slangasek: so then its not really a bug at all. The interface needs to be listed in /etc/network/interfaces. :)
[20:12] <slangasek> SpamapS: why not avoid emitting static-network-up when only lo is up?  nfs-kernel-server won't be the only package with an init script that hits a problem like this
[20:12] <SpamapS> slangasek: hrm. Well we'll slow down boot speed quite a bit waiting for DHCP
[20:13] <slangasek> SpamapS: I thought you server guys all agreed robust > fast ;)
[20:13] <SpamapS> slangasek: we do, but this particular  user is a desktop user.
[20:13] <SpamapS> slangasek: and NetworkManager != robust IMO
[20:14] <slangasek> hmm
[20:14] <slangasek> oh blast, lightdm is start on ... runlevel
[20:15] <SpamapS> yeah
[20:15] <slangasek> right, we don't want to slow that down in the desktop case :/
[20:15] <SpamapS> another option is to integrate with insserv a bit and only delay if something that has Require-Start: $network in it.
[20:16] <slangasek> nah, I think we probably should just worry about moving nfs-kernel-server to upstart
[20:19] <SpamapS> slangasek: what would we make the start on condition though? I think runlevel [2345] would still make more sense than 'net-device-up IFACE!=lo' ...
[20:19] <SpamapS> and filesystem and all that jive
[20:19] <slangasek> hmm
[20:19] <SpamapS> because what you really want is all static network interfaces up. :-P
[20:20] <slangasek> no, for nfs what you want is "the network up"
[20:20] <slangasek> staticness notwithstanding :)
[20:20] <SpamapS> static is a terrible term and I must apologize for its use.
[20:20] <SpamapS> server-network-up maybe? ;)
[20:21] <slangasek> maybe
[20:21] <slangasek> except that, as we see here, that's not always conclusive
[20:21] <SpamapS> anyway, I haven't found a sane way to express it generically without having a special "I'm a desktop" flag somewhere.
[20:21] <slangasek> yeah
[20:21] <slangasek> well, punting for now then
[20:22]  * SpamapS is still glad we had to work through to the roadblock.. learning can be useful
[20:26] <ahasenack> hi guys, can someone take a look and hopefully approve the following SRU updates that are sitting in the unapproved queue? smart for lucid, maverick and natty
[20:26] <ahasenack> and landscape-client for maverick and natty
[20:26] <ahasenack> I believe they are not in proposed yet, lacking such an approval
[20:37] <SpamapS> ahasenack: I'll look at them when I get back from lunch.
[20:37] <ahasenack> SpamapS: cool, thanks
[21:57] <slangasek> bdmurray: could you analyze the apport data on bugs 849414 and 533745 (and duplicates) to see if there's a pattern in the hardware in use?  (Video hardware in particular)
[21:57] <slangasek> bdmurray: I don't think we're going to get to the bottom of this bug without a dev reproducing this in a controlled environment - i.e., running plymouth under valgrind or the like
[21:57] <slangasek> so step one is to be able to reproduce it at all...
[21:58] <bdmurray> step 2 ? and step 3 is fix it!
[21:59] <slangasek> step 2 is raiding the fridge for snacks
[21:59] <tedg> Uhm, I'm getting signature errors of archive.ubuntu.com.
[21:59] <tedg> Like GPG errors on the package list.
[21:59] <tedg> Is anyone else having issues?
[22:00] <slangasek> tedg: probably my fault; try again in 10-20 minutes
[22:00] <tedg> slangasek, Okay.  Cool.  Was getting a little nervous there :-)
[22:00] <slangasek> hand-running the publisher during milestone prep has acquired a new and exciting failure mode
[22:02] <Daviey> slangasek: Do you know if jhunt is working on bug 818177?
[22:03] <slangasek> Daviey: he's on vacation this week, so I would think "not right now"
[22:04] <Daviey> slangasek: vacation! /me looks up what this means.
[22:04] <Daviey> slangasek: fwiw, we seem to be seeing that issue on iscsi aswell now, not just LVM.
[22:05] <hallyn> and on virtio with no iscsi or lvm
[22:05] <Daviey> anything with slower io, by the seems of it.
[22:05] <hallyn> and faster io, just less frequently
[22:05] <hallyn> (at least, i'm assuming it's the same thing as what i see in kvm vm's every 5-10 boots)
[22:05] <Daviey> hallyn: maybe even medium speed io at freq' between that of fast and slow?
[22:06] <hallyn> uh
[22:06] <hallyn> heck maybe that's why my euca instances occasionally don't come up
[22:06] <hallyn> and why my milk didn't taste right this morning
[22:07] <slangasek> no, the milk thing sounds like a dupe of a multiarch bug
[22:07] <Daviey> Seems reasonable to attribute that to udev.
[22:07] <Daviey> And this has all happend because jhunt went on vacation.  Damn Brits.
[22:07] <bdmurray> slangasek: Does this help? http://pastebin.ubuntu.com/694067/
[22:08] <hallyn> socialists
[22:08]  * hallyn out - i'm going to do some debugging later tonight.  if you (anyone) finds anything more out, can you comment it in that bug so I don't duplicate effort?
[22:08] <slangasek> bdmurray: hmm... less than it would if they all matched, but thanks :) good to know what we're looking at
[22:09] <bdmurray> slangasek: that's from 849414 and its duplicates
[22:09] <slangasek> bdmurray: ack
[22:11] <slangasek> bdmurray: seems there are 5 video cards reported twice each - are these two dupes each from the same submitter, or is it actually more common on some hardware than on others?
[22:15] <Daviey> bdmurray: does your bug bot check for Short read in buffer_copy" error with "dpkg"
[22:15] <Daviey> ?
[22:15] <bdmurray> Daviey: yes
[22:16] <Daviey> bdmurray: how often does it run?
[22:16] <bdmurray> slangasek: only one duplicate is from the same reporter
[22:16] <slangasek> bdmurray: interesting, thanks
[22:17] <bdmurray> Daviey: every 4 hours
[22:17] <Daviey> bdmurray: thanks
[22:18] <bdmurray> Daviey: did it miss one?
[22:18] <Daviey> bdmurray: hmm, let me check the timestamps
[22:21] <Daviey> bdmurray: ah, it was <2 hours.. so no.. i just beat the bot.
[22:22] <SpamapS> slangasek: hah, async fail.. I responded to bug 848823 reversing my position before seeing the email that you wrote reversing yours. :)
[22:23] <SpamapS> worst.. chess players.. ever
[22:23]  * slangasek grins
[22:23] <SpamapS> slangasek: I think its doable if we make static-network-up aware of NetworkManager's connections that are going to be brought up at boot time.
[22:23] <slangasek> SpamapS: well, if there's a good way to query that, yes
[22:26] <SpamapS> slangasek: right, thats the bit I'm not sure of. Either way, I think its worthwhile as a Medium bug in upstart (upstart owns the static-network-up event)
[22:27] <Daviey> Turn the importance up to 11.
[22:27] <SpamapS> /o/
[22:29] <slangasek> SpamapS: how does upstart own it?  /etc/network/if-up.d/upstart is in ifupdown
[22:31] <SpamapS> slangasek: indeed it is.. doh. ok.. well then back to ifupdown the bug goes.
[22:31] <slangasek> alrighty... :)
[23:11] <chrisccoulson> bryceh, ah, this is going to be fun. that drm delay only happens at startup, so i can't just run another xserver manually with strace :/
[23:12] <bryceh> chrisccoulson, erf