[00:00] <Gnostus_> Is there any sort of tool that can unencrypt a copy/pasted message encrypted from PGP, problem is that im hooked up to yahoo(boo) and from what im seeing theres alot of hoops as im not paying for there pop service :\
[00:00] <micahg> robert_ancell: well, it seems to need something from gio (or lightdm is exporting something it shouldn't maybe) per the build log failure
[00:01] <micahg> haha, it's using gio :), the issue is probably --as-needed :)
[00:01] <robert_ancell> micahg, do you have a debian system to test on?  ldd /usr/lib/liblightdm-gobject-1.so for me shows it correctly linked against on Ubuntu
[00:04]  * micahg is checking in a chroot
[00:04] <micahg> oh, Debian only has 1.0.6
[00:11]  * micahg wonders why liblightdm-gobject-1-0 is in a multiarch patch in Debian and not in Ubuntu
[00:11] <micahg> s/patch/path
[00:11] <micahg> FWIW, 1.0.6 in Debian is linked against gio-2.0
[00:13] <cjwatson> RAOF: all copied for the next publisher run
[00:13] <cjwatson> (I believe.  Feel free to chec)
[00:13] <cjwatson> +k
[00:13] <RAOF> Where will tha tbe showing up?  precise-changes?
[00:14] <cjwatson> Not sure, but hopefully.  They'll be in publishing histories though
[00:15] <cjwatson> e.g. https://launchpad.net/ubuntu/+source/xorg-server/+publishinghistory
[00:15] <micahg> manual copies usually don't end up in -changes from what I've seen
[00:30] <bdmurray> I'm looking at some initramfs-tools bugs and there are a few package install failures with the following in them
[00:31] <bdmurray> cp: not writing through dangling symlink `/etc/initramfs-tools/modules'
[00:31] <bdmurray> when I sawy a few I mean 5 and 2 of the 5 mention parallels on a mac
[00:34] <bdmurray> and I don't know of a way to tell if the others are using parallels
[00:35] <bdmurray> bug 913631 is an example
[00:38] <psusi> is dh_translations also appropriate for debian?
[00:45] <stgraber> bdmurray: a blog post I found mentions the vmware tools and I confirmed that the bug you posted above is on a system with openvm-vm-* installed (VMWare guest tools)
[00:45] <stgraber> bdmurray: can you see if that's the case for all of them?
[00:45] <stgraber> bdmurray: http://jerram.tumblr.com/ is the blogpost
[00:46] <stgraber> bdmurray: (I looked at the package list that was contained in the apt-clone tarball, but you can probably find the same in the logs)
[00:49] <bdmurray> stgraber: wow, I forgot what a mess that aptclone attachment is
[00:51] <stgraber> bdmurray: yeah, you need to gzip -d, then rename to .tar.gz then unpack :)
[00:51] <bdmurray> stgraber: I think I'll fix that.
[00:51] <stgraber> that'd be great :)
[00:52] <bdmurray> which package did you find?
[00:53] <bdmurray> oh open-vm
[00:53] <stgraber> open-vm-dkms, open-vm-source, open-vm-toolbox and open-vm-tools
[00:53] <bdmurray> you'd said openvm-vm earlier
[00:55] <bdmurray> regardless I don't see it in a couple of others
[00:57] <stgraber> bdmurray: any chance you can get them to paste "ls -l /etc/initramfs-tools" in the bug?
[00:57] <stgraber> bdmurray: seeing where the symlink is pointing to would make figuring out the source a lot easier :)
[00:58] <bdmurray> stgraber: sure, I'll ask
[01:03] <psusi> is dh_translations also appropriate for debian, or is that an ubuntu thing?
[01:05] <cjwatson> $ grep Ubuntu /usr/bin/dh_translations
[01:05] <cjwatson>             push @result, "X-Ubuntu-Gettext-Domain=$domain\n";
[01:05] <cjwatson>         push @result, "X-Ubuntu-Gettext-Domain=$domain\n";
[01:05] <cjwatson> at the very least it ought not to be used on Debian without some thought and work
[01:05] <cjwatson> it's not in Debian
[01:06] <psusi> damn
[01:07] <psusi> I was just about to merge a new upstream gparted with all ubuntu changes to debian and resync, and someone added dh_translations
[01:09] <psusi> so now I guess I'll have to wait for the debian upload, and merge it back to ubuntu keeping the translations local...
[02:49] <superm1> kirkland: general practice thus far has been linux-headers-generic | linux-headers, which should hit any of the desktop/server machines that have gone through an ubuntu installer proper I believe
[02:49] <kirkland> superm1: okay, thanks
[02:49] <superm1> it's when people start going and mucking with alternate kernels or kernels from PPAs that problems come up
[02:49] <kirkland> superm1: i think that's what we've got so far
[02:49] <superm1> but generally those people are intelligent enough to figure out the problem too i suspect
[02:49] <kirkland> superm1: yeah, i've had trouble characterizing *when* people get into trouble
[02:51] <superm1> kirkland: and actually dkms itself is the one pulling in those recommends too
[02:51] <kirkland> superm1: hmf
[02:51] <superm1> Recommends: fakeroot, menu | sudo, linux-headers-686-pae | linux-headers-amd64 | linux-headers-generic | linux-headers, linux-image
[02:52] <superm1> so possibly are these people who are ignoring recommends by default?
[02:53] <micahg> hmm...seems like an implementation detail best left to dkms
[02:53] <kirkland> superm1: i'll have to check, but thanks for the pointers and sanity checks
[02:53] <superm1> sure
[02:54] <superm1> if you encounter some more details about a failing scenario i'll be glad to try to help accommodate within reason
[02:54] <kirkland> superm1: thanks
[02:54] <kirkland> superm1: i'll let you know
[02:54] <superm1> ok
[03:47] <robert_ancell> pitti, ping
[05:05] <pitti> Good morning
[05:06] <pitti> stgraber: argh, sorry, I totally missed the TB meeting; need to fix my calendar
[05:06] <pitti> hey robert_ancell
[05:09] <robert_ancell> pitti, hey, mfisch was trying to use the LightDM GIR bindings but the objects don't have any methods.  Can you see anything wrong with them?
[05:09] <robert_ancell> pitti, e.g. 'from gi.repository import LightDM; l = LightDM.Greeter(); dir(l)' shows nothing
[05:10] <pitti> robert_ancell: which package ships the .gir file?
[05:10] <pitti> liblightdm-gobject-1-dev I suppose
[05:10] <robert_ancell> pitti, liblightdm-gobject-1-dev
[05:10] <robert_ancell> yup
[05:13] <pitti> oh, Greeter is a struct
[05:14] <pitti> robert_ancell: it does show stuff; apart from the standard __ bits, it has "parent_instance"
[05:14] <pitti> robert_ancell: the .gir does not specify any other field in Greeter
[05:14] <pitti> robert_ancell: it has a "GreeterClass" struct with some fields, though
[05:14] <robert_ancell> pitti, so it's not being recognised as a GObject?
[05:15]  * pitti bzr pulls trunk and has a look
[05:15] <pitti> robert_ancell: src/greeter.h looks the same, though
[05:15] <pitti> robert_ancell: struct Greeter with just a parent_instance
[05:16] <pitti> apparently it doesn't pick up the functions anywhere, though
[05:17] <pitti> robert_ancell: OOI, why did you make it a struct and functions, instead of an actual class?
[05:17] <robert_ancell> it is a class afaict
[05:19] <pitti> robert_ancell: oh, I see
[05:19] <pitti> robert_ancell: you build the .gir from liblightdm-gobject/
[05:19] <pitti> robert_ancell: and only include the .c files from there
[05:19] <pitti> you also need to include the source files from src/ if you want to expose the server-side methods
[05:20] <pitti> but I suppose that's not actually intended? If you just want to use the library API, then src/greeter.c should not actually be exposed?
[05:20] <robert_ancell> pitti, no, I don't want to expose the server side stuff
[05:21] <pitti> ok, so e. g. greeter_set_allow_guest() sohuldn't be exposed (it's from src/greeter)
[05:21] <pitti> but lightdm_greeter_connect_sync ought to be exposed
[05:22] <robert_ancell> yes
[05:22] <robert_ancell> pitti, oh, this looks oddc: symbol-prefixes="light_dm"
[05:22] <pitti> *nod*
[05:22] <pitti> built from "LightDM" namespace
[05:22] <pitti> robert_ancell: let me build the source, I added --warn-all to INTROSPECTION_SCANNER_ARGS
[05:23] <pitti> robert_ancell: hah, --warn-all shows why
[05:24] <pitti> robert_ancell: I think it's a good idea to commit that, and then fix all the warnings; want me to push the --warn-all
[05:24] <pitti> ?
[05:24] <robert_ancell> yes please
[05:24] <pitti> (done)
[05:24] <pitti> user.c:135: Warning: LightDM: invalid annotation option: tranfer
[05:24] <pitti> lightdm/greeter.h:71: Warning: LightDM: symbol='lightdm_greeter_get_type': Unknown namespace for symbol 'lightdm_greeter_get_type'
[05:24] <pitti> robert_ancell: ^ very useful
[05:26] <robert_ancell> pitti, thanks a lot!
[05:26] <pitti> let me spend a minute on the namespace bug
[05:26] <robert_ancell> pitti, setting --symbol-prefix seems to fix it
[05:26] <robert_ancell> (pushed)
[05:27] <pitti> hah, that's what I was trying indeed
[05:27] <pitti> robert_ancell: you can drop --identifier-prefix=LightDM BTW, it's the default
[05:27] <pitti> i. e. it defaults to the name of the GIR
[05:27] <pitti> (but it doesn't hurt)
[05:27] <pitti> now, no warnings at all
[05:28] <pitti> robert_ancell: ah, and now it's a proper class, too
[05:44] <pitti> cjwatson: the syncs in https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1 look wrong; do you need them for examination, or can I remove them?
[05:47] <pitti> cjwatson: oh, hang on -- are these the result from "sru-release", i. e. copying from -proposed?
[05:47] <pitti> looks like the recent KDE 4.7.4 SRU
[05:49] <pitti> cjwatson: these already seem to be in -updates, though
[06:17] <pitti> jibel: I see my test scripts in https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lts/PROFILE=lts-ubuntu,alderamin-upgrade=alderamin-upgrade/19/consoleText , nice!
[06:17] <pitti> jibel: however, it seems it ran the prepare_user.sh bit as root?
[06:17] <pitti> jibel: sorry, the test_upgrade_user.py as root
[06:18] <pitti> jibel: and can you change it to run the test_upgrade_user.py one through dbus-launch?
[06:18] <pitti> jibel: for test_lts_upgrade_system.py, I think the missing autologin migration is known
[06:19] <pitti> robert_ancell: ^ do you plan to read /etc/gdm/custom.conf at first lightdm installation and copy over the autologin-user value  from it?
[06:19] <pitti> robert_ancell: we have an automatic upgrade test case for this now (migrating autologin settings)
[07:43] <jibel> pitti, good morning
[07:43] <pitti> jibel: bonjour, ca va?
[07:43] <jibel> pitti, ça va et toi ?
[07:43] <pitti> je suis bien, merci!
[07:45] <jibel> pitti, prepare_user is run with sudo as user ubuntu, should I run it with dbus-launch too ?
[07:46] <pitti> jibel: yes please
[07:46] <pitti> jibel: presumably you also need -H
[07:46] <pitti> jibel: it seems it's trying to get the background from /root/ otherwise
[07:47] <pitti> jibel: i. e. sudo -H -u ..
[07:47] <jibel> pitti, no, background is not preserved on upgrade
[07:48] <pitti> hm, interesting
[07:48] <jibel> pitti, theme, keyboard and language settings are lost too
[07:48] <pitti> do you get a /home/ubuntu/my_background.jpg after the prepare script?
[07:48] <jibel> pitti, yes, I also ran the upgrade manually
[07:49] <jibel> and checked the settings before and after upgrade from system settings to make sure the script was right.
[07:49] <pitti> ok, that's something to investigate then
[07:50] <jibel> pitti, i'll do one more upgrade this morning and will file bugs
[07:50] <pitti> merci
[07:51] <jibel> pitti, but at least launchers are preserved and moved to unity launcher.
[07:51] <jibel> desktop launchers are also preserved is desktop was not renamed from french to english
[07:52] <jibel> s/is/if
[07:52] <dholbach> good morning
[07:52] <pitti> jibel: right, the automatic test still fails, presumably because it's looking in /root/ again instead of /home/ubuntu
[07:52] <pitti> hey dholbach
[07:52] <dholbach> hey pitti
[07:53] <jibel> pitti, i'll check that
[07:53] <jibel> morning dholbach
[07:53] <pitti> jibel: I hope sudo -H and dbus-launch will fix that
[07:53] <dholbach> salut jibel - comment ça va?
[07:59] <jibel> dholbach, ça va, et toi ?
[07:59] <dholbach> jibel, oui, ça va, j'ai seulement besoin d'un petit peu de café  ;-)
[08:32] <tjaalton> shouldn't 'bts' work on ubuntu too? I see emails sent from my machine but not doing anything on the debian BTS
[08:33] <tumbleweed> tjaalton: I don't see any reason why it wouldn't work on ubuntu
[08:33] <tjaalton> right..
[08:33] <pitti> tjaalton: WFM
[08:33] <Laney> it certainly does work
[08:33] <Laney> you need a working MTA though
[08:34] <Laney> or --smtp-host
[08:34] <tjaalton> ok so just to get this right; i'm trying to mark a bunch of bugs to block one, so I ran 'bts block xxx by yyy zzz'
[08:35] <tjaalton> MTA works
[08:39] <tjaalton> I'll try another smtp server
[08:43] <tjaalton> that helped..
[09:16] <pitti> SpamapS: do you know about the status of bug 580319 for lucid, in particular 10.04.4? Is that something that's realistic to get fixed still, or should we drop it from the milestone list?
[09:28] <pitti> ev, cjwatson: does ubiquity already have a convenience function/method to determine when it's in "only-ubiquity" mode? (it doesn't seem to check /proc/cmdline for that)
[09:28] <pitti> I need this for bug 712677, i. e. call apport-gtk for only-ubiquity, and only write the .crash for live session mode
[09:30] <ev> pitti: that's determined outside of ubiquity, in the upstart job
[09:31] <ev> as it affects the options passed to ubiquity-dm
[09:31] <ev> but all it is, as you point out, is an option in /proc/cmdline
[09:32] <pitti> ev: right, I saw that; I just found it curious that nothing else in ubiquity works differently in only-ubiquity mode
[09:32] <pitti> ev: so I guess I'll implement my own check then
[09:32] <ev> so we could just spawn it off of ubiquity-dm
[09:32] <ev> apport, that is
[09:32] <pitti> you mean "it" == update-notifier?
[09:32] <pitti> I don't think we need the full thing
[09:33] <ev> ohhh, right, update-notifier does the inotify watch, doesn't it?
[09:33] <pitti> yes
[09:33] <pitti> until we get user session upstart jobs and inotify triggers for jobs
[09:33] <pitti> ev: ok, thanks! just wanted to ensure that I don't duplicate something
[09:33] <ev> those would be very nice
[09:33] <ev> sure thing
[09:36] <pitti> hm, actually.. if ubiquity crashes with e. g. a segfault, the ubiquity-builtin excepthook doesn't actually help us
[09:37] <pitti> so yes, maybe running through the piled up crashes in ubiquity-dm after ubiquity finishes is better after all
[09:48] <pitti> jibel: oh, calling gsettings-data-convert segfaults; that might explain why the gconf settings are not migrated during upgrade
[09:48] <pitti> seb128: ^ known?
[09:48] <seb128> pitti, depend what schemas is missing
[09:48] <pitti> if I call that on a live system, I get an error message about a missing unity-2d "use-strut" key, and then a segfault
[09:48] <seb128> pitti, there are known issue, can you get the assert error? it should tell you what schemas,key is buggy
[09:48] <pitti> sorry, no segfault, assertion
[09:48] <seb128> yeah, that's known
[09:49] <pitti> com.canonical.Unity2d.Launcher use-strut
[09:49] <pitti> seb128: ok, thanks; that's a likely candidate for the failing user config migration test
[09:50] <ara> hello pitti!
[09:51] <pitti> hey ara, long time no see!
[09:51] <ara> pitti, true! :)
[09:51] <ara> pitti, one quick question, what are the chances of python-qt4 making it to the CD on precise? :)
[09:51] <pitti> ara: in the current state, pretty much zero
[09:52] <pitti> ara: it's about 13 MB compressed
[09:52] <pitti> and we are 11 MB oversized
[09:52] <ara> and is it anybody working in making it smaller?
[09:52] <pitti> no to my knowledge; maybe
[09:53] <pitti> it could be split into submodules
[09:53] <ara> OK, but, to be on the safe side, better not using it
[09:53] <pitti> but even then it would still use some 4 or 5 MB, which is still heavy
[09:53] <seb128> pitti, hum, I can't find the bug now, maybe it was mentioned somewhere but not filed
[09:53] <seb128> pitti, but feel free to open an unity-2d bug
[09:54] <seb128> pitti, they list a key in their .convert which is not in the schemas
[09:54] <ara> pitti, OK, thanks!
[09:56] <pitti> seb128: probably bug 875590 and dupes (I'll mark a few)
[09:56] <pitti> seb128: still, should the whole thing fail because of one wrong schema?
[09:57] <seb128> pitti, no, that one is bug #916441
[09:57] <seb128> pitti, i.e a shotwell schemas
[09:58] <pitti> indeed, duping
[09:58] <seb128> pitti, " thing fail because of one wrong schema?" <- tell desrt, that's how gsettings is designed
[10:00] <seb128> pitti, it's the "gsettings abort on missing schemas" discussion we have regularly
[10:00] <pitti> *nod*
[10:01] <pitti> seb128: ok, added an unity-2d task
[10:01] <pitti> seb128: thanks!
[10:01] <seb128> pitti,  to what bug?
[10:01] <pitti> (will look at it soon)
[10:01] <pitti> bug 916441
[10:01] <seb128> :-(
[10:02] <seb128> pitti, I hope the yorba guys don't get annoyed by getting "spammed" by unity-2d comments
[10:02] <seb128> let's see
[10:02] <seb128> but thanks ;-)
[10:02] <pitti> well, it's the same crash, and apport will dupe them all there anyway
[10:02] <seb128> it's not, it's buggy schemas in 2 different applications
[10:02] <pitti> and we need to fix all broken schemas; that's pretty much exactly what bug tasks are for?
[10:02] <seb128> it's like saying "it's 2 aborts"
[10:02] <pitti> it's _exactly_ the same abort
[10:03] <pitti> we can't tell apport that the same crash is caused by two different data files from different packages
[10:03] <seb128> well it's like saying "abort on a missing icons" are dups when the icons and softwares are different
[10:03] <seb128> right
[10:04] <seb128> well still doing it this way means that i.e shotwell subscriber will get email for bugs in unity-2d
[10:04] <pitti> jibel: ^ so you can use above bug for the data migration for now; once that's fixed, we should re-check
[10:05] <seb128> pitti, I will remove the shotwell component and use another bug for shotwell, I really don't want to spam the yorba guys about buggy schemas in other applications
[10:05] <seb128> let's keep that one for unity-2d
[10:06] <pitti> well, then let's keep that for shotwell, to keep the already existing comments
[10:06] <pitti> and create a new one for unity-2d
[10:06] <pitti> but it'll still be misleading for crash reporters
[10:06] <pitti> as they will be led to the shotwell one
[10:06] <pitti> but *shrug*
[10:06] <seb128> pitti, we can keep a gconf bug for apport dup master if you want
[10:07] <seb128> then open bugs about buggy softwares and add comments about those on the gconf bug
[10:07] <seb128> let's rename the master "the schemas migration should ignore buggy schemas"
[10:08] <jibel> pitti, ok. Is there a way to find this bug from the logs or during upgrade, any test I could add ?
[10:08] <pitti> jibel: you should have a gsettings-data-convert crash in /var/crash
[10:09] <pitti> jibel: but doesn't the test_lts_upgrade_user.py thing cover this now?
[10:09] <pitti> seb128: or that, WFM
[10:13] <jibel> pitti, nothing in /var/crash but the post-upgrade test covers this indirectly.
[10:16] <pitti> seb128: bug 920894, removed unity-2d task from other one
[10:16] <seb128> pitti, thanks
[10:16] <pitti> now, we can't really fix one without the other, but as we don't have bug dependencies, we'll have to track it manually
[10:16] <seb128> pitti, ?
[10:17] <seb128> pitti, we can fix the .convert individually
[10:17] <pitti> I mean, if we fix shotwell, it still affects shottwell
[10:17] <cjwatson> pitti: oh, hah, is *that* what happened to them - I forgot they were going to go through the queue
[10:17] <pitti> it'll still crash
[10:17] <cjwatson> pitti: feel free to reject them, as I copied them separately
[10:17] <pitti> seb128: anyway, we discussed it now, it's fine
[10:17] <seb128> pitti, right
[10:17] <seb128> pitti, btw I will backport http://git.gnome.org/browse/gconf/commit/?id=120f116e608bc1f09cf65435333e40e00c6b8ad2
[10:18] <pitti> seb128: \o/
[10:18] <pitti> that'll help indeed
[10:18] <seb128> pitti, but that will not sort those cases, that's not missing schemas but broken keys listed
[10:18] <pitti> seb128: so we sohuld reassign 916441 to gconf after all?
[10:18] <seb128> pitti, no, in those cases the schemas is there, the .convert just list a key which is not in the schemas
[10:19] <pitti> ah, I see
[10:19] <seb128> which is a variant that git commit will not fix
[10:19] <pitti> cjwatson: done; so that's not through sru-release? (as that seems to work, at least my version)
[10:21] <pitti> bbl, need to go to the dentist again
[10:38] <cjwatson> pitti: I had a locally modified sru-release that used Archive.copyPackage
[10:38] <cjwatson> pitti: so that might actually work then - I just need to make it print a warning to go and prod the queue
[10:38] <cjwatson> pitti: (or ideally have a queue API so that it could do it itself)
[11:42] <pitti> cjwatson: ah, thanks
[11:42] <pitti> yeah, auto-accepting from the queue would be nice indeed, but I guess a warning to do it manually would do for now
[11:43] <cjwatson> no rush, it can wait until we have a queue API I think
[11:44] <cjwatson> I was trying to get around Archive.syncSource timeouts without resorting to copy-package.py :)
[11:44] <cjwatson> of course auto-accepting from the queue requires waiting for the PCJ to run :-(
[11:45] <cjwatson> (PackageCopyJob - Archive.copyPackage is async ...)
[11:45] <pitti> oh, nice! no more timeouts?
[11:45] <pitti> that's still better than having to ssh
[11:45] <pitti> which we have to do for every kernel update, and a lot of other packages like gtk or unity
[11:46] <cjwatson> It's async, but doesn't report failures anywhere useful right now, so can be a bit confusing
[11:46] <cjwatson> but yes, it is likely the ultimate solution for that kind of problem
[12:03] <hrw> can someone take a look at http://people.linaro.org/~hrw/ubuntu/multiarch/elfutils.deb.diff and share opinion?
[12:05] <hrw> it is not perfect probably but I managed to build few packages (rpm, kcov, systemtap, makedumpfile) with resulting packages.
[12:06] <tumbleweed> is there any point in moving the stuff to multiarch locations if you aren't marking the binaries MultiArch: same ?
[12:07] <hrw> ah, forgot that part
[12:07] <hrw> tumbleweed: I want to be able to install :amd64 and :armel at same time for kernel/perf compilations
[12:08] <tumbleweed> right. otherwise, the diff looks sane
[12:09] <hrw> tumbleweed: Standards-Version needs update but this part is a thing which I have to learn
[12:09] <hrw> tumbleweed: and thanks for review
[12:10] <geser> isn't the debhelper compat level tied to the debhelper major version (as a lower bound)?
[12:10] <tumbleweed> we try to avoid unecessary changees in debian (such as bumping standards version)
[12:10] <tumbleweed> err in Ubuntu
[12:11]  * tumbleweed actually tries a build of that
[12:11] <hrw> geser: http://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools says ">= 8.1.3" + compat/9
[12:11] <geser> ok then
[12:11] <hrw> tumbleweed: I am considering sending patch to debian
[12:12] <hrw> tumbleweed: otherwise this work is useless
[12:12] <doko> TheMuso, could you write a MIR for java-atk-wrapper?
[12:12] <tumbleweed> hrw: that's always good. still, the standards-version  bump is unrelated (except that a newer standards version is required to specify multiarch)
[12:13] <hrw> ok
[12:13] <hrw> ~curse m4
[12:16] <tumbleweed> hrw: well, it doesn't bulid, test failure :)
[12:16] <hrw> tumbleweed: pastebinit please
[12:19] <tumbleweed> hrw: unrelated, I think, I get it withotu the patch too
[12:19] <hrw> tumbleweed: anyway I am interested if you can share them
[12:20] <tumbleweed> http://paste.ubuntu.com/815293/ could be something about my build environment (eatmydata + aufs)
[12:21] <hrw> maybe. here all 70 passed
[12:22] <hrw> now I need to dig out older gcc-4.6 and rebuild my cross compiler for one test
[12:27] <tumbleweed> hrw: it's being confused by the chroot's full (from the outside) filenames in /proc/self/maps
[12:39] <hrw> ok, sent to debian
[12:39] <hrw> should I wait for Debian or can I search for sponsor to get it in Ubuntu archive?
[12:43] <tumbleweed> hrw: We already have a delta, so unless that's been superseded in debian, I don't see any reason not to upload to Ubuntu directly. But, as a non-core-dev, I can't help there.
[12:50] <geser> hrw: depends on how active the DD is and how urgent you need it in Ubuntu (does it block you?)
[12:53] <hrw> geser: no, it does not block me so I can wait
[13:47] <jdstrand> hallyn: hey. reading your libvirt-bin diff, am I right in understanding that everyone must now have a default network and that package upgrades will unconditionally enforce that?
[13:48]  * diwic boots into a new X stack, seems to work fine so far
[14:18] <cjwatson> bilal: could you please merge scim-chewing from testing?  it fails to build in precise right now, and it looks as though a simple merge should fix it
[14:19] <cjwatson> (you're the last uploader)
[14:26] <hallyn> jdstrand: no.  the opposite.  In the past it would always, on upgrade, re-enable the default net.
[14:26] <hallyn> jdstrand: now the intent is to check whether the default net autostart symlink exists, and only recreate it on new installs or if it already existed
[14:27] <hallyn> jdstrand: so if you have custom networking and have deleted the autostart symlink, then upgrades won't mess with your networking, like they used to
[14:27] <hallyn> unfortunately that has been a lot harder for me to get right than i expected
[14:39] <slangasek> mvo: heya, we seem to have stalled out somewhere on the apt merge question; what's the current status, and is there something I can do to help it along?
[14:40] <slangasek> tumbleweed: thanks for your fixes to submittodebian, btw - it's working much more smoothly for me now :)
[14:40] <tumbleweed> slangasek: np
[14:42] <mvo> slangasek: I uploaded a bunch of stuff to debian-experimental now, if that looks solid, that will be what we use too, I had a issue with libept1 as that needs to change the binary package name when the libapt abi changes to avoid double linking against old libapt and new libapt
[14:44] <slangasek> mvo: hmm, ok (time for symbol versioning in libapt? :)
[14:48] <pitti> ev: I didn't commit the fix right away, but put it into a MP: https://code.launchpad.net/~pitti/ubiquity/only-ubiquity-crashes/+merge/89916
[14:48] <pitti> ev: I tested it and it works, but I'd still appreciate a second pair of eyes, especially on the exit(1) and some general style issues
[14:49] <mvo> slangasek: that and for getting rid of the current global symbols
[14:52] <glenn___> jodh: im sorry, it was not my intention to get off topic
[14:57] <jdstrand> hallyn: ok cool. I didn't read the whole postinst. thanks for explaining
[14:57] <hallyn> jdstrand: hopefully I've finally got it right.  Maybe the moral is that it can't be done 100% right, and that's why debian just doesn't do net autostart by default at all.
[14:57] <hallyn> i'm learning...
[15:01] <ev> pitti: just one comment. Looks good though.
[15:02] <pitti> ev: reason> mostly, not knowing about it :)
[15:02] <ev> :)
[15:02] <pitti> ev: will try again with that
[15:02] <ev> cheers
[15:02] <pitti> I suppose it will just work, but it was fiddly enough to get working that I'd like to actually see this myself
[15:05] <psusi> pitti: you merged a patch the other day to gparted to use dh_translations, which you also seem to be the author of.  I was just about to resync ubuntu to debian's gparted.  Is it possible to set it up in such a way that it does not disturb debian?
[15:05] <pitti> psusi: debian/rules, yes, but not the build dependency
[15:05] <pitti> we don't have "opportunistic" build dependencies unfortunately
[15:06] <pitti> psusi: the only workaround known to me is to build depend on cdbs, which pulls in dh-translations on ubuntu, but not in Debian
[15:06] <psusi> pitti: and debian doesn't even have the dh-translations package?
[15:06] <pitti> psusi: or we need to go back to doing things manually, but Gabor found something wrong with that previously
[15:07] <pitti> psusi: no, they don't have langpacks and all that
[15:07] <psusi> pitti: would it be possible to get a dummy package into debian that would satisfy the depend, and do nothing?
[15:08] <pitti> psusi: you could do a hack like B-D: dh-translations | frozen-bubble :)
[15:08] <psusi> why muddle the depend line?  just make a dh-translations package on debian that is just a no-op
[15:08] <cjwatson> not sure even that works; IIRC Debian's sbuild always wants the first alternative
[15:08] <pitti> psusi: I guess if we want to sync, we could just do the translation stuff in debian/rules; which can then be protected by dpkg-vendor --is ubuntu
[15:09] <pitti> cjwatson: yeah, it really was a joke
[15:09] <pitti> if we do b-d hacks, then adding cdbs would be less ugly
[15:10] <pitti> psusi: oh -- you can b-d on gnome-pkg-tools
[15:10] <SpamapS> pitti: re bug 580319 , its my understanding that 10.04.4 is frozen.. or has hat been extended?
[15:10] <psusi> wouldn't it be easier to just have an actual dh_translations helper script in debian so the rules file doesn't need modified, and just their version wouldn't actually do anything?
[15:10] <pitti> psusi: that's small, harmless, and will DTRT
[15:10] <psusi> pitti: but you'd still need to modify rules to switch on dpkg-vendor right?
[15:10] <glenn___> jodh: regarding upstart: should the exit code of "status ssh" be not 0 if ssh is not running
[15:11] <pitti> psusi: and then in rules, something like "if dh -l | grep -q ^translations"; then --with translations, etc.
[15:11] <pitti> psusi: easier, yes, but we don't have it right now, and getting it into Debian takes some time (not to mention the political discussion of "cluttering" their package namespace with it)
[15:11] <SpamapS> pitti: also the fix that we did in 11.10 has been fairly controversial.. so I don't think it can be a straight backport
[15:12] <stgraber> pitti: added what I hope is a detailed testcase to bug 889423 (for bridge-utils, will do the same for vlan and ifenslave-2.6 when they land). Didn't mark it verification-done as I'm the one who did the actual changes, so hopefully we can get someone to run the same tests or if you're satisfied with what I posted, feel free to change the tag yourself.
[15:12] <psusi> hrm...
[15:12] <slangasek> SpamapS: mysql-5.5 debian/watch seems to be broken
[15:12] <slangasek> SpamapS: also, do you want to push an update to debian/changelog so I can build straight from svn ):
[15:13] <stgraber> pitti: also, I think I'd prefer to have all 3 of them land at the same time as at least ifenslave calls the two others. They don't strictly depend on each other, but the bug won't be fully resolved until they all get updated.
[15:13] <slangasek> :)
[15:13] <pitti> SpamapS: frozen in the sense that we control what goes in now
[15:13] <pitti> SpamapS: ack, let's drop the milestone then
[15:16] <Daviey> cjwatson: Would you be able to comment on bug 920749 please? Thanks.
[15:18] <pitti> stgraber: right, I ignored one for now, as it seemed way too intrusive for a quick review; thanks for the heads-up
[15:19] <pitti> ev: yep, works fine
[15:19] <ev> great
[15:19] <pitti> pushed
[15:19] <pitti> (to my branch)
[15:19] <ev> cool, I'll merge now
[15:20] <SpamapS> slangasek: right I didn't want to --release until you ack'd. ;)
[15:21] <SpamapS> pitti: for bug 711425, I'm comfortable waiting until after 10.04.4 to let that into -updates ..
[15:21] <ev> pitti: merged; thanks for this!
[15:21] <pitti> ev: thanks!
[15:22] <slangasek> SpamapS: ok - let me do a test-build here and confirm that myodbc builds against it without further problems first :)
[15:22] <pitti> SpamapS: hm, you think it's too unsafe for 10.04.4? it's marked for this point release, after all
[15:22] <stgraber> pitti: yeah, ifenslave-2.6's delta is pretty big, if looking closely you'll notice it's mostly code being moved around into separate functions with the actual addition being maybe 30 lines of code (the whole, locking, waiting and calling vlan/bridge-utils hooks part).
[15:23] <cjwatson> Daviey: linked to the upstream bug which has more than enough commentary for anyone
[15:23] <cjwatson> Daviey: I'll have a think about it
[15:24] <pitti> need to run for today, see you tomorrow!
[15:29] <Daviey> cjwatson: thanks!
[15:31] <cjwatson> Daviey: I don't think I accept the milestoning though, sorry.  This has been present forever and there doesn't seem a need to rush into a solution without upstream.
[15:31] <cjwatson> Particularly since it's not entirely impossible that the best fix might involve changing both OpenSSH and PAM.
[15:37] <cjwatson> nuclearbob: has there been any progress with getting the conflict checker up to date?
[15:39] <nuclearbob> cjwatson: not as much as I'd like.  I've been pulled onto updating reporting projects for my team a lot.  I'll try to wrap those up and get back onto the conflict checker ASAP.
[15:53] <SpamapS> pitti: its safe enough, but not worth blocking 10.04.4 on.. it hasn't been verified yet
[15:53] <SpamapS> pitti: and I think it may even be short a couple days on the 7 day rule too
[15:59] <cjwatson> pitti: any progress on getting firefox into lucid-updates?  I'm conscious that we haven't been able to build .4 DVDs yet
[16:13] <ev> pitti: stack traces to StacktraceAddressSignature is a one to many relationship, right?
[16:16] <jbicha> kees: are you around?
[16:19] <dholbach> kirkland, you rock!
[16:20] <tumbleweed> anyone know how much RAM our biggest arm buildds have?
[16:37] <ScottK> tumbleweed: Not enough.  There's some issue with ram usage on arm so we can't build large packages that used to build like qtwebkit-source.
[16:43] <brendand> anyone here can talk about the HUD?
[16:45] <seb128> brendand, better on #ubuntu-unity
[16:46] <brendand> seb128 - is that a real channel?
[16:46] <brendand> on Freenode?
[16:46] <brendand> eh, typo - sorry
[16:46]  * brendand typed ubunty-unity
[16:47] <jalcine> jono: ping
[16:47] <jono> jalcine, howdy
[17:00] <psusi> pitti: the man page for dh_translations says that it fixes up desktop files... in that merge commit, X-Ubuntu-Gettext-Domain was added to the desktop.in.in file via patches/01_fix-desktop.patch.  Shouldn't that change be left out of the main sources and it's added when dh_translations is run?
[17:07]  * kirkland high-fives dholbach ;-)
[17:16] <slangasek> tumbleweed: what's the problem you're running into (ARM)?
[17:25] <tumbleweed> slangasek: I'm going to run into trouble with pypy
[17:25] <tumbleweed> actually, already have
[17:30] <jdstrand> mdeslaur: when you disabled network-manager/dnsmasq integration, did you just remove this line from /etc/NetworkManager/NetworkManager.conf: dns=dnsmasq
[17:30] <mdeslaur> jdstrand: yes,I just commented it out
[17:30] <jdstrand> mdeslaur: thanks
[17:30] <SpamapS> pitti: did you forget to @pilot out?
[17:31] <slangasek> jdstrand, mdeslaur: hmmm, why are you guys disabling the dnsmasq integration?  I thought the current solution was one that passed muster with the security team; are there bugs?
[17:32] <jdstrand> slangasek: I'm not sure if there is a bug there or not. I am trying to figure it out
[17:32] <slangasek> ok
[17:33] <mdeslaur> slangasek: I was having trouble looking up libvirt guests and disabled it, I haven't turned it back on yet as the dnsmasq issue isn't fixed yet AFAIK
[17:33] <slangasek> alrighty
[17:33] <jdstrand> slangasek: I do still need to fiddle with resolvconf as we discussed before for working with libvirt-- I think mdeslaur opted out of resolvconf
[17:33] <slangasek> I've never had libvirt guest lookup working here fwiw; would love to have that figured out
[17:34] <jdstrand> it used to work great with resolvconf as per https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment#Networking_with_libvirt
[17:34] <mdeslaur> slangasek: easy, use 192.168.122.1 as your dns server
[17:34] <jdstrand> well, previous dnsmasq releases needed you to append '.' to the host name
[17:34] <slangasek> oh, it requires manual configuration?  Well no wonder ;)
[17:35] <slangasek> so if libvirt could integrate with resolvconf that'd be peachy
[17:35] <slangasek> oh right
[17:35] <slangasek> that's the bug, that integrating with resolconf is no longer sufficient ;)
[17:35] <jdstrand> that seemed to be fixed in 11.10 or 12.04...
[17:35] <jdstrand> 12.04 is weird though-- sometimes the lookups work and sometimes not
[17:35] <slangasek> hmm
[17:36] <mdeslaur> jdstrand: oh? seems to work reliably for m
[17:36] <mdeslaur> me
[17:36] <jdstrand> I still have to hup dnsmasq occasionally
[17:36] <jdstrand> I haven't figured out why
[17:36] <mdeslaur> jdstrand: oh, yeah, me too...it stops responding after a while
[17:37] <mdeslaur> but, rebooting every 8 hours because compiz stops displaying my firefox windows mitigates the issue nicely
[17:37] <jdstrand> so I guess saying it works 'fine' is overselling it
[17:37] <jdstrand> it works ok most of the time
[17:37] <jdstrand> mdeslaur: pfft
[17:37] <mdeslaur> jdstrand: hehe
[17:38] <jdstrand> seriously? I haven't had that since upgrading to precise :)
[17:38] <jdstrand> (actually 11.10 was pretty solid by the time we released too)
[17:38] <mdeslaur> jdstrand: yeah, I still get it with precise
[17:38] <elmo> JOOI, what's the rationale for the dnsmasq stuff in network-manager?
[17:38] <jdstrand> weird..
[17:39] <jdstrand> elmo: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-resolving
[17:39] <elmo> jdstrand: thanks
[17:41] <jdstrand> hmmm
[17:42] <slangasek> actually, I'm not sure that blueprint answers the question
[17:42] <jdstrand> well, there is stgraber's final comment in 2011-12-13 that I think sums it up
[17:43] <slangasek> oh, so it does
[17:43] <slangasek> 'sabit buried though
[17:43] <kirkland> wow, 92 updates today?  did 11.10 -proposed just get cleaned out today?
[17:44] <jdstrand> so, aiui, dnsmasq will look at /etc/hosts for name resolution, itself if it is a dhcp server (eg libvirt) and then the other entries in /etc/resolv.conf for forwarders
[17:44] <slangasek> er?  why would dnsmasq look at /etc/hosts?
[17:44] <slangasek> that's nss's job
[17:44] <jdstrand> I'm almost sure it does
[17:45] <jdstrand> ie, when traveling I hup dnsmasq after making changes to /etc/hosts and can resolve stuff
[17:45] <slangasek> and no, it doesn't look at the other entries in /etc/resolv.conf; it has its own server list, /var/run/nm-dns-dnsmasq.conf
[17:46] <slangasek> jdstrand: why would you need to hup *anything* to reflect changes in /etc/hosts?
[17:46] <jdstrand> slangasek: ah, maybe in this network manager configuration
[17:46] <jdstrand> huping dnsmasq flushes its cache
[17:46] <bdmurray> stgraber: bug 917905 might be interesting to look at
[17:47] <jdstrand> man dnsmasq: It loads the contents of /etc/hosts so that local hostnames which do  not appear  in  the global DNS can be resolved and also answers DNS queries for DHCP configured hosts.
[17:47] <slangasek> jdstrand: yes, but what are you doing that /etc/hosts isn't already being used directly via /etc/nsswitch.conf?  Or is this about exporting your /etc/hosts entries to the guests?
[17:47] <slangasek> hrm
[17:48] <cjwatson> kirkland: I moved a bunch of stuff to oneiric-updates yesterday
[17:48] <jdstrand> slangasek: I do it for guests, yes
[17:48] <mdeslaur> jdstrand: you mean /etc/resolv.conf, not /etc/hosts
[17:48] <cjwatson> don't think I even cleared the list but there was certainly a lot of it
[17:48] <slangasek> jdstrand: gotcha
[17:48] <kirkland> cjwatson: so i noticed ;-)
[17:48] <slangasek> mdeslaur: no, it really does both :)
[17:48] <kirkland> cjwatson: thanks
[17:48] <cjwatson> it was mostly mechanical :)
[17:49] <cjwatson> apw: bug 921096 might be worth somebody having a look at, since it has upstream attention
[17:50] <apw> cjwatson, is there some upstream discussion going on do you know ?
[17:50] <cjwatson> apw: Eric Sandeen got in touch with me about it on IRC
[17:51] <cjwatson> since he was initially puzzled as to the cause
[17:51] <cjwatson> I don't think there's any other discussion yet, seeing as that was just in the last few minutes
[17:52] <jdstrand> I'm still curious about the interplay of the nm dnsmasq and the libvirt dnsmasq and the fact that 192.168.122.1 is listed first and what effect that has on name resoltuion. I don't have time to dig in but am curious if my change makes things better for me
[17:52] <apw> cjwatson, my memory of the change was it was partition specific, so i suspect it won't handle whole disks without partitions
[17:52] <jdstrand> if it does, I'll investigate more
[17:52] <cjwatson> he said he'd see if Fedora might have a similar problem though; it would in principle affect any distro that ever shipped with default libata.ignore_hpa=1
[17:52] <apw> yeah
[17:54] <slangasek> stgraber: which design oversights of resolvconf were you intending to correct yet, btw?
[17:55] <stgraber> slangasek: I think that WI was basically for what you already fixed (using /run, upstart job tweaks)
[17:55] <slangasek> ok
[17:55] <slangasek> guess we should DONE it then :)
[17:55] <stgraber> slangasek: indeed
[17:57] <stgraber> slangasek: the only thing I saw was broken since I switched to resolvconf on my machines is arkose as /run isn't bind mounted in the container by default, making /etc/resolv.conf point to well, nowhere. But that's a trivial bug to fix in arkose's defaults.
[17:57] <apw> cjwatson, it is not clear to my mind if it is possible to guess the users intent if the mount the entire drive.  did they mean just the beginning or all of it
[17:57] <slangasek> stgraber: <nod>
[17:58] <stgraber> slangasek: I'll try and have a look at dhclient this afternoon see what exactly needs fixing, once that one is done, we should be ready to have resolvconf enabled by default
[17:59] <slangasek> stgraber: I think the dhclient bit is low-priority, actually, since that code path is not hit in the normal usage
[17:59] <cjwatson> apw: we can't guess their intent, but if we don't find a partition table on the drive then we could check to see whether there seems to be a filesystem there
[17:59] <slangasek> (should still be fixed, doesn't need to block resolvconf-by-default)
[17:59] <cjwatson> in principle, anyway ...
[18:00] <apw> cjwatson, then we'd need to know how to know how big every filesystem thought its container is ... not very nice
[18:01] <apw> i know ... lets get grub to do it :)
[18:01] <stgraber> slangasek: right. Wondering about the exact timing we want for it. Do you think we should ask for more testers on ubuntu-devel before doing the seed change?
[18:02] <stgraber> slangasek: at the same time I'd like to have it switched on for alpha-2 so we don't have a whole lot of time for additional testing...
[18:04] <slangasek> stgraber: ironically, with the nm change to dnsmasq resolvconf-by-default is very low-risk for the dekstop because it hardly has to do anything... maybe just poke some server folks to test before flipping the switch?
[18:05] <stgraber> slangasek: indeed, it's really low-risk on desktop. I'll poke #ubuntu-server and make sure the server team do a quick test of their stuff using it
[18:05] <cjwatson> apw: can't the filesystem code probe a filesystem and tell you how long it is
[18:05] <cjwatson> ?
[18:06] <cjwatson> apw: the reports are of backup disks, btw, there's no reason to assume that they're plugged in at boot ;-)
[18:06] <apw> cjwatson, they should know how much space they have in them, whether they have a highest block number referenced is less obvious
[18:06] <cjwatson> hmm
[18:07] <cjwatson> well, this is Eric's kind of area so might be worth talking to him about it
[18:07] <hallyn> jodh: http://lkml.org/lkml/2012/1/23/535   So if we have to update /usr/share/initramfs-tools/init and some other places to make sure /dev/ptmx is a symlink to /dev/pts/ptmx and that devpts is mounted with 'ptxmode=666', would that seem acceptable to you?
[18:07] <apw> cjwatson, most FSs probabally do know as it is quite common to read the first and last block to make sure you have the entire media
[18:07] <stgraber> slangasek: now as to where we want to put it. Does having it as a recommend of ubuntu-standard sounds good to you?
[18:07] <apw> cjwatson, where is he talking to you
[18:08] <cjwatson> apw: /msg
[18:08] <apw> ahh
[18:09] <slangasek> stgraber: I was pondering whether it shouldn't be a recommend of those packages which would update /etc/resolv.conf previously (dhcp-client, network-manager)
[18:10] <apw> cjwatson, we would also not want to do this until you tried to mount the fs either in case you wanted to zap things and become conformant
[18:10] <slangasek> since it's only needed if you have a dynamic network
[18:10] <cjwatson> apw: eww, so the bdev might change length in flight?
[18:11] <apw> well that must happen now when hpa drops during partition discovery ... but yes not ideal
[18:11] <stgraber> slangasek: if I remember my seeds correctly, that'd basically make it installed on anything with ubuntu-minimal then
[18:12] <slangasek> stgraber: does that seem incorrect to you?
[18:12] <slangasek> cjwatson: ^^ or to you (having resolvconf pulled into ubuntu-minimal)?
[18:13] <stgraber> slangasek: it's not "wrong" but it'll definitely be annoying to me ;) Most containers on my network run with a template /etc/resolv.conf (pushed by bcfg2, a puppet like tool), these containers only have ubuntu-minimal installed
[18:13] <stgraber> slangasek: and unfortunately bcfg2 as far as it sounds doesn't quite support removing packages ;)
[18:14] <slangasek> stgraber: well, let's see then
[18:15] <slangasek> stgraber: /etc/resolv.conf is turned into a symlink at resolvconf install time; but if you change it back, resolvconf becomes a no-op
[18:15] <cjwatson> I do tend to think that it should be a recommendation of a real package not a metapackage
[18:15] <slangasek> stgraber: would that still be inconvenient in your case?
[18:15] <cjwatson> recommending it from isc-dhcp-client does seem not entirely risk-free though
[18:15] <cjwatson> recommending it from network-manager seems easy enough
[18:16] <stgraber> cjwatson: the idea was to have it everywhere, not just desktops, so we need to have somthing on servers pull it too
[18:16] <slangasek> cjwatson: however, n-m isn't on the server and my intent is that if we're going to do this, we do this across the board
[18:16] <slangasek> and make it the standard interface for /etc/resolv.conf updates that it always aspired to be
[18:16] <slangasek> (and own the bugs, if any)
[18:16] <stgraber> slangasek: indeed, I forgot it properly handles the case where we turn /etc/resolv.conf back into a file (or at least should)
[18:17] <cjwatson> well, if you want it across the board, then probably recommends of isc-dhcp-client *and* ubuntu-minimal
[18:17] <stgraber> slangasek: what happens on upgrade though (not that it really matters, my configuration manager would overwrite it again an hour later), do we turn it back into a symlink at upgrade time or just at initial install time?
[18:18] <slangasek> stgraber: only at install time
[18:20] <slangasek> cjwatson: well, u-m already depends on isc-dhcp-client, so I guess that's redundant
[18:21] <stgraber> slangasek: perfect then. No problem having it be a recommends of ubuntu-minimal (or something in ubuntu-minimal if we prefer that).
[18:22] <cjwatson> slangasek: it is, but do you want it to be the default resolv.conf updater only on systems using DHCP, or on all systems?
[18:23] <cjwatson> redundancy isn't necessarily bad depending on what the intent is
[18:23] <slangasek> cjwatson: all systems... but to me it seems that the right way to represent this is as a depends/recommends of the packages that feed the dynamic resolver info
[18:24] <cjwatson> OK - is there anything other than isc-dhcp-client and network-manager that does that?
[18:24] <slangasek> bind
[18:25]  * slangasek searches
[18:26] <cjwatson> dnsmasq?
[18:26]  * slangasek swats the 'openresolv' search results out of the way
[18:26] <stgraber> I don't know if we can trust resolvconf but if we can:
[18:26] <stgraber> Enhances: isc-dhcp-client, dhcpcd, pump, udhcpc, ppp, ifupdown, network-manager, bind9, dnsmasq, pdnsd, totd, libc6, nscd
[18:27] <cjwatson> seems like a lot to get right - I think I'd definitely like a metapackage recommendation *in addition* if we want this as the system default
[18:27] <stgraber> it definitely contains hooks for bind, ifupdown, ppp and dhclient. NM has code to detect and use resolvconf, not sure for the others
[18:28] <slangasek> "hooks for bind" - it's the other way around; bind's init script calls resolvconf
[18:29] <slangasek> ultimately these packages should be gone through and have their NIH code for updating resolv.conf shot in favor of a dependency
[18:29] <slangasek> but yeah, for now I think u-m depending is reasonable
[18:33] <stgraber> slangasek: depending or recommending?
[18:33] <slangasek> stgraber: hair-splitting :-)
[18:33]  * stgraber starts working on the MIR as resolvconf is still in universe
[18:34] <slangasek> I guess I'd do a Depends
[18:35] <slangasek> phooey
[18:35] <slangasek> SpamapS: ../driver/.libs/libmyodbc5.so: undefined reference to `dynstr_append_mem'
[18:36] <slangasek> this may not actually be your problem though, let's see
[18:36] <infinity> resolvconf was in universe for pretty solid reasons, way back when... Has it drastically improved in sanity since?
[18:36] <slangasek> infinity: yes, I took a hatchet to it
[18:37] <infinity> slangasek: Shiny.
[18:49] <stgraber> slangasek: bug 921135 hopefully doko will have a few minutes to review ;)
[18:59] <slangasek> SpamapS: ok, so these myodbc missing symbols are a change in mysql-5.5; I guess there's a linker script somewhere that's suppressing these symbols from being exported, but they're needed by "external" packages (myodbc)?
[19:10] <tumbleweed> ScottK: ok, so there's no chance of pypy building on ARM. I can live with that, keeps things simple :)
[19:11] <ScottK> Not at the moment.  That may change.
[19:11] <tumbleweed> yeah, long  term we'll want it to
[19:11] <tumbleweed> JIT for ARM is still under development, anyway
[19:20] <stgraber> slangasek: hmm, looking at it now, I believe dhclient's behaviour when resolvconf is installed is actually correct
[19:20] <slangasek> stgraber: in /sbin/dhclient-script itself?
[19:20] <stgraber> slangasek: /etc/dhcp/dhclient-enter-hooks.d/resolvconf (shipped by resolvconf) defines make_resolv_conf() as basically "return 0", so dhclient won't mess with resolv.conf anymore
[19:20] <slangasek> oh, interesting
[19:20] <stgraber> slangasek: then re-defines it to do the right thing
[19:21] <slangasek> should resolvconf have to do that, though?  or should this be regarded as a bug in isc-dhcp-client?
[19:21] <stgraber> so asumming the scripts are always sourced, it should work fine
[19:21] <slangasek> but, well, at that point we can still defer and take it up with the Debian maintainer instead of introducing a delta
[19:22] <stgraber> well, it seems like resolvconf is in the habit of providing hooks to integrate with name server, dhcp clients, ... so it doesn't seem completely wrong to do it this way
[19:23] <stgraber> right, all the hooks are sourced and the enter hooks are basically the first thing dhclient-script executes, so that seems good to me
[19:27] <stgraber> slangasek: btw, just tried booting with all persistent file systems mounted read-only (in my case, only /) and Ubuntu now boots and has network
[19:27] <stgraber> slangasek: lightdm doesn't start though :)
[19:27] <slangasek> nice :)
[19:27] <slangasek> the first part, not the second ;)
[19:27] <SpamapS> slangasek: myodbc uses private internal API's from mysql.. its *evil*
[19:28] <slangasek> SpamapS: yes, but it's evil that needs to be buildable :)
[19:28] <SpamapS> slangasek: so typically it will have a specific version that it is meant to be compiled with
[19:29] <slangasek> SpamapS: that has certainly not been my experience historically, but it's certainly possible that upstream maintenance has gone to hell
[19:30] <stgraber> slangasek: rebooting with upstart logging turned on to see how many upstart jobs explode because of the lack of writable filesystem (assuming I can get upstart to dump the logs once I remount / read/write)
[19:30] <SpamapS> slangasek: upstream being our fine friends at Oracle. ;)
[19:31] <slangasek> stgraber: fwiw, I do feel strongly that having resolvconf override the code in dhclient-script this way is the wrong way about, but it's not critical to fix right now
[19:31] <SpamapS> btw, did we all decide it was ok for NetworkManager to own 127.0.0.1:53 ? I can see this being a problem for some people.. running dnsmasq and always pointinga t 127.0.0.1 in /etc/resolv.conf
[19:33] <stgraber> slangasek: noted :) probably worth opening a bug in Debian, we already have a huge delta on isc-dhcp IRIC so would be nice to have that bit done in Debian instead
[19:33] <slangasek> SpamapS: I actually had bind installed and running here when I first upgraded to the dnsmasq-enabled NM, and didn't notice any problems; of course bind was here only as a caching nameserver anyway so I subsequently removed it
[19:33] <SpamapS> slangasek: its really confusing to have to dive down the rabbit hole and find the "real" dns server instead of just looking at /etc/resolv.conf :p
[19:33] <slangasek> stgraber: huh, yes, we ought to re-sync with Debian on this
[19:33] <stgraber> slangasek: I believe NM can actually deal with bind too, I think cyphermox showed me some code doing that
[19:34] <slangasek> SpamapS: yep, I realize - that's mentioned in the blueprint
[19:34] <stgraber> SpamapS: on a desktop, clicking on "Connection Information" in the NM applet will always give you the right thing
[19:35] <stgraber> SpamapS: or "nm-tool" from the command line which gives you that + a whole bunch of other potentially useful information
[19:35] <stgraber> (and yeah, I still run cat /etc/resolv.conf multiple times a week ... will get used to it eventually ...)
[19:35] <slangasek> SpamapS: anyway, there's no new upstream version of myodbc out; and it may not have worked with 5.5.17 either since we never got that far in the build due to the _r issue
[19:36] <SpamapS> slangasek: indeed, I think I tried it on Ubuntu and got a similar problem
[19:36] <slangasek> SpamapS: I suspect that no one build-tested myodbc on Linux, and this happens to work on Windows because of a lack of linker script there
[19:36] <SpamapS> slangasek: entirely possible it wants an *older* release
[19:36] <cyphermox> stgraber: correct, NM has code that could allow you to use bind as the caching nameserver
[19:36] <SpamapS> slangasek: nobody tests anything regarding shared libraries in mysql-land
[19:37] <SpamapS> that goes back pre-Sun days..
[19:37] <slangasek> heh, right
[19:37] <SpamapS> slangasek: we may need to patch it... <sigh>
[19:37] <slangasek> cyphermox: so what does that code do in light of this dnsmasq setting, if you have bind running?
[19:37] <slangasek> SpamapS: yep!  do you happen to know where this linker script is hiding?
[19:38] <cyphermox> SpamapS: if you want to know about the DNS servers from the cli you can sudo cat /run/nm-dns-dnsmasq.conf or nmcli con status id  "whatever the name of your connection is"
[19:38] <cyphermox> slangasek: it doesn't touch bind, not sure what you mean otherwise?
[19:39] <slangasek> cyphermox: does it try to *start* dnsmasq?
[19:39] <cyphermox> slangasek: do you mean what resolvconf or whatnot would do if two caching nameservers are running?
[19:39] <cyphermox> slangasek: yeah, if the setting is dns=dnsmasq it will try to start it
[19:39] <slangasek> cyphermox: no, because you *can't* have two caching nameservers running on the same IP
[19:39] <stgraber> slangasek: I suspect you'd need to manually change the dns line in /etc/NetworkManager/NetworkManager.conf to refer to bind instead of dnsmasq, assuming we actually build that plugin
[19:39] <cyphermox> obvioulsy.
[19:39] <slangasek> so does NM do something sensible when :53 is already in use?
[19:40] <cyphermox> well, there would be an error message in syslog, but for the rest I'll have to check
[19:40] <slangasek> I think that'd be a good thing to check
[19:40] <slangasek> cyphermox: btw, I notice that NM is actually pointing dnsmasq at /var/run, not /run :)
[19:41] <slangasek> (minor issue)
[19:41] <SpamapS> slangasek: likely deep within the bowels of 5.5's cmake build
[19:41] <cyphermox> file a bug, I'll fix it, there's already other things in the "queueueue"
[19:41] <stgraber> slangasek: what'd be sensible for you? using the existing DNS server and hoping it's right, overriding /etc/resolv.conf as NM used to or fail to connect?
[19:41] <cyphermox> (I mean of things to work on in NM, I'll get to it very soon)
[19:41] <slangasek> SpamapS: oh... right, cmake :P
[19:42] <slangasek> cyphermox: bug for which one?
[19:42] <slangasek> stgraber: #2
[19:42] <cyphermox> bug for /var/run
[19:42] <slangasek> well, except not overriding /etc/resolv.conf, but using resolvconf instead :P
[19:43] <slangasek> cyphermox: I don't actually care about the /var/run enough to file a bug report :)
[19:43] <cyphermox> slangasek: alright, I'll try to think about it when I next look at the code :)
[19:45] <ogra_> hmpf, i seem to have lots of themeing issues with the new X
[19:46] <cyphermox> slangasek: stgraber: ok, looks like it already handles the case where biind or dnsmasq fail to start, and avoids adding 127.0.0.1 to resolvconf then
[19:46] <stgraber> cyphermox: does it instead add the DNS servers directly to resolvconf?
[19:47] <cyphermox> stgraber: yup
[19:48] <stgraber> sounds good then
[19:49] <cyphermox> wouldn't hurt to test this just in case, but the nameservers only get changed to 127.0.0.1 if the plugin succesfully starts
[19:55] <jodh> hallyn: as long as it's fully tested of course: plymouth started from initramfs uses ptys...
[19:56] <nessita> hello everybody! would anyone know when is the next Developer Membership Board meeting? https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda seems outdated (though I can guess the next date, I would like official confirmation :-))
[19:57] <dobey> also, would a packageset request go to dmb or tech board?
[19:58] <hallyn> jodh: frankly i haven't yet found where the final /dev/ptmx (at login) comes from.  I create a symlink in initrams's init, and do it again at /etc/init/mount-dev.conf, but i still get a simple device
[19:59] <slangasek> hallyn: does it not just come from devtmpfs?
[19:59] <hallyn> jodh: are you on linux-kernel m-l?
[19:59] <hallyn> slangasek: I rm that one. oh!  maybe udev is doing it
[19:59] <hallyn> slangasek: well, i rm that one at mounted-dev.conf
[20:00] <slangasek> hallyn: there is a ptmx add event in /var/log/udev for me, certainly
[20:00] <hallyn> slangasek: if it were that simple, at least we could fix that in the kernel
[20:00] <slangasek> and it's listed in /lib/udev/rules.d/50-udev-default.rules
[20:00] <hallyn> slangasek: yeah i'd forgotten about that.  lemme see if that helps.  thanks
[20:00] <jodh> hallyn: not currently.
[20:01] <hallyn> slangasek: jodh: if you want to chime in on the email thread with any concerns, that'd be great :)
[20:01] <stgraber> dobey: dmb
[20:01] <hallyn> ok, off to test with udev
[20:02] <hallyn> oh, no, that one just sets the perms
[20:08] <cyphermox> nessita: Jan 30th, according to the parent page.
[20:08] <dobey> stgraber: cool, thanks. can you or someone update the wiki so there's a new agenda for the meeting next monday? :)
[20:08] <dobey> cyphermox: i think she wants to add her bid for package upload privs to the agenda :)
[20:09] <cyphermox> oh, I know
[20:09] <cyphermox> nessita: I think you can just add your name to the agenda, but normally they ask for one full week heads up, and you should send an email to the DMB mailing list
[20:12] <nessita> cyphermox: yes, I was to send the email, when I couldn't find the agenda for the next meeting. And my next question was is the full-week in advance is a hard requirement :-)
[20:12] <nessita> anyways, I have no problem  waiting for the meeting after that
[20:13] <stgraber> nessita, dobey: done. Btw, we usually ask for a week notice when asking for upload rights but 6 days notice is probably fine too, not like we have much on the agenda to prepare for :)
[20:13] <nessita> I don't wanna go against the policies
[20:13] <nessita> stgraber: I have no problem waiting for the meeting after that, really
[20:13] <cyphermox> nessita: fwiw, I've been asked to abide by that rule in the past ;)
[20:14] <nessita> cyphermox: and makes sense :-)
[20:14] <stgraber> nessita: we have nothing to discuss at our next meeting so far, and didn't have anything at our last meeting, so feel free to add your item to the agenda :)
[20:15] <nessita> stgraber: sounds great, thanks
[20:16] <stgraber> nessita: also make sure to e-mail your request to devel-permissions@lists.ubuntu.com
[20:17] <nessita> stgraber: doing that atm, but I was trying to find the agenda for the next meeting to add my name to it
[20:18] <nessita> stgraber: my confusion is that the MOTU app that is in https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda was also for the meeting of the 16th, so perhaps the page is not ready for the next meeting?
[20:18] <stgraber> nessita: it's been there for a few months
[20:19] <nessita> ok, so I'll leave it there and add my name
[20:19] <nessita> thanks!
[20:19] <stgraber> nessita: it's an application we decided to move to e-mail (that's what the "(E)" means) but never got an answer back from the applicant
[20:20] <stgraber> nessita: we'll probably drop it from the agenda soon as it's just confusing people
[20:20] <nessita> heh
[20:20]  * nessita was confused indeed
[20:38] <stgraber> slangasek: ok, so lightdm not starting in read-only mode is cause by X needing /tmp and /var/log/ to be writable to start, then lightdm fails if /var/lib/lightdm isn't writable. Once these two are worked around, I still can't open a session :)
[20:41] <stgraber> slangasek: now the only error in network logs cause by / being read only is /etc/dhcp/dhclient-enter-hooks.d/samba (samba-common) trying to write to /etc/samba/dhcp.conf.new an then moving that file to dhcp.conf. This failure might prevent other dhclient or ifupdown scripts from running (now that ifupdown checks for return codes)
[20:42] <stgraber> udev-finish is also complaining it can't move /dev/.udev.log to /var/log/udev but that was to be expected and doesn't prevent anything from running (at least that I could find)
[20:43] <infinity> stgraber: Surely, it can't be a goal to have a read-only /tmp and /var? :P
[20:43] <infinity> stgraber: Or is this a case of "even if your FS explodes, it would be nice to be able to start a session"?
[20:44] <stgraber> infinity: yeah, it was mostly out of curiosity that I was checking how much of the desktop would start without a writable /
[20:45] <stgraber> infinity: the /etc stuff seems more problematic though as someone could definitely have /etc read-only on purpose
[20:47] <stgraber> infinity: our default partitioning scheme is to have a big / + a swap partition, / is mounted with errors=remount-ro so in case of some filesystem weirdness, I now know that someone will get a nice black screen on vt7 with nothing starting (on a desktop, on a server you should at least get to vt1 and a login prompt)
[20:56] <infinity> stgraber: Things writing to /etc are definitely bad.  But yeah, I agree that it would be nice if / was remounted ro, your system should still kinda work.
[21:09] <TheMuso> doko: One has already been written and it has been approved. Just a minute, and I'l get you a bug number.
[21:10] <TheMuso> doko: bug 849729
[21:24] <doko> TheMuso, oh, thanks. then I just need to re-promote.
[21:25] <hallyn> smoser: it's showing the ipxe rom name.  does it actually say it's trying to boot from pxe?  Does it look the same as when you do -boot n?
[21:27] <slangasek> stgraber: samba-common - definitely a bug, I think it may have been reported in Debian already
[21:35] <stgraber> slangasek: can't find one in the Debian BTS after a quick look (but the list is pretty long so might have missed it)
[21:36] <slangasek> yeah... :)
[21:37] <slangasek> yeah, I don't see it either
[21:37] <semiosis> soren: ping?
[21:37] <slangasek> so maybe it wasn't a bug; maybe it was a piece of fuzz in my brain
[21:37] <maxb> Anyone around who knows how apt-xapian-index and software-center integrate? I have update-apt-xapian-index throwing warnings about unconfigured python loggers in software-center code.
[21:41] <soren> semiosis: wazzup?
[21:43] <semiosis> soren: i resubmitted the merge request, just wondering if you might have a chance to check it out.
[21:43] <semiosis> soren: deleted the first try because i messed up my bzr branch... learning bzr the hard way :)
[21:43] <soren> semiosis: Sorry, no, haven't gotten around to it yet. Do you have the link handy?
[21:43] <semiosis> yes
[21:45] <semiosis> soren: https://code.launchpad.net/~semiosis/ubuntu/precise/glusterfs/fix-for-876648/+merge/88603
[21:47] <soren> semiosis: You know.. I think SpamapS will do a much better job reviewing that upstart job than I.
[21:47] <soren> SpamapS: Would you mind taking a look?
[21:47] <semiosis> soren: ok he actually helped point me in the right direction when i was starting to work on it
[21:47] <semiosis> soren: was thinking about getting back in touch with him
[21:48] <semiosis> SpamapS: do you remember?  http://irclogs.ubuntu.com/2011/04/12/%23upstart.txt
[21:51]  * SpamapS takes a look
[21:52] <SpamapS> +start on (local-filesystems and net-device-up IFACE=lo and net-device-up IFACE=eth0) or (mounting TYPE=glusterfs)
[21:52] <SpamapS> semiosis: that is really convoluted.
[21:53] <semiosis> :D
[21:53] <slangasek> more to the point, it probably doesn't work reliably
[21:53] <semiosis> the goal is to have it start once local filesystems are mounted and the network interfaces are up... or when trying to mount a glusterfs type filesystem.
[21:53] <SpamapS> semiosis: do local gluster mounts *need* glusterd running?
[21:54] <SpamapS> semiosis: you may need a separate "glusterd-wait" job to achieve that
[21:54] <semiosis> SpamapS: if the gluster mount tries to mount from localhost, then yes.  that is, if the machine is a server & a client
[21:54] <semiosis> SpamapS: if the gluster mount is mounting from a remote host, then no glusterd is required at all.
[21:55] <semiosis> SpamapS: and likewise a server with glusterd need not have any client mounts itself
[21:55] <semiosis> SpamapS: perhaps it is convoluted but people have been using it with success.  i distribute it in a ppa
[21:56] <cjwatson> that kind of (foo and bar) or baz trick is known to trigger upstart bugs
[21:56] <cjwatson> it has to either be split up or simplified
[21:57] <cjwatson> https://bugs.launchpad.net/upstart/+bug/447654
[21:57] <SpamapS> in this case, all of those are "signals", and not waited on..
[21:57] <cjwatson> oh, hm, that's "foo and (bar or baz)"
[21:57] <cjwatson> you might get away withit
[21:57] <cjwatson> *with it
[21:57] <SpamapS> but the assumption that eth0 is the one needed for glusterd to work is incorrect
[21:57] <semiosis> cjwatson: it works pretty well actually
[21:57] <semiosis> SpamapS: fair point
[21:58] <SpamapS> semiosis: in 11.10 and later, you can replace all of that with 'runlevel [2345]'
[21:58] <cjwatson> semiosis: with an event-driven system you can't rely just on empirical evidence, you have to analyse it too
[21:58] <SpamapS> semiosis: but the mounting bit.. will cause you issues
[21:58] <SpamapS> semiosis: I know it works for others, however, there is a race condition there, albeit subtle
[21:59] <cjwatson> I don't think you hit the standard "and" operator problem, at least
[22:00] <SpamapS> semiosis: if you are mid 'starting' and the mounting event arrives, upstart will not block the 'mounting' event, because it only blocks when the goal is changed from stop->start...
[22:00] <SpamapS> semiosis: and mounting can arrive at *any* time because it happens any time net-device-up is emitted
[22:01] <semiosis> SpamapS: ok if it gets a mounting event & tries to start but is already started, whats the problem?
[22:01] <SpamapS> semiosis: so, in order to make that work, you need to use a second job and 'start wait-for-state'
[22:02] <SpamapS> semiosis: its already *starting* .. but it may take a few seconds, and meanwhile your mount fails because its not ready yet
[22:02] <cjwatson> SpamapS: all of those are signals> is that true for local-filesystems and mounting?
[22:02] <SpamapS> semiosis: you need to wait until glusterd is running. Which.. btw.. sleep 1.. is also fairly trivial and may not work in all cases.
[22:03] <SpamapS> cjwatson: all of the and'd conditions are signals (including local-filesystems). Mounting is or'd.. but carries its own problems.
[22:03]  * SpamapS is trying to find the bug which talks about not blocking unless you change the goal..
[22:03] <cjwatson> SpamapS: maybe I'm reading the mountall code wrongly but I thought it blocked
[22:04] <SpamapS> cjwatson: mounting definitely blocks
[22:04] <SpamapS> cjwatson: but that one is in an or.. so it should be ok.
[22:04] <semiosis> fyi, bug is described here: https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/876648
[22:04] <SpamapS> cjwatson: or.. is that also a problem when used in conjunction with and?
[22:04] <cjwatson> ah, you're right, local-filesystems doesn't block
[22:05]  * SpamapS has never thought of this scenario actually
[22:05] <cjwatson> no, I think it's OK here
[22:06] <cjwatson> the problematic scenario would be: (1) net-device-up IFACE=lo arrives; (2) net-device-up IFACE=eth0 arrives; (3) mounting TYPE=glusterfs arrives; (4) this job starts; (5) local-filesystems arrives and blocks because the other conditions are now no longer met
[22:06] <cjwatson> or similarly for the other elements of the conjunction
[22:06] <cjwatson> still, I would avoid this construction because it's fragile and all too easy to innocently edit into a state where it can cause boot hangs
[22:07] <SpamapS> Yeah, and truly, those other constraints are all met by 'runlevel [2345]' in 11.10 and later
[22:08] <SpamapS> the mounting case can be handed by a wait-for-state job
[22:08] <semiosis> ok i will try the runlevel [2345] solution that wasn't around when i wrote this
[22:08] <semiosis> SpamapS: can you point me to an example of a wait-for-state job?
[22:09] <SpamapS> http://paste.ubuntu.com/815874/
[22:09] <SpamapS> that should do it
[22:10] <semiosis> oooh nice
[22:10] <SpamapS> actually
[22:10] <SpamapS> http://paste.ubuntu.com/815875/
[22:10] <SpamapS> WAITER is required
[22:10]  * SpamapS really should write a man page for wait-for-state :-P
[22:11] <semiosis> +1 for man pages
[22:11] <SpamapS> semiosis: now, about that sleep 1
[22:12] <SpamapS> semiosis: ideally glusterd would fork after it is ready to listen, though I am guessing it doesn't do that
[22:12] <semiosis> actually i gave it the no-fork option because i thought thats how upstart liked it.
[22:13] <semiosis> i guess expect-fork is the way to go now?
[22:13] <SpamapS> well that is fine, but that means your post-start needs to be careful and do more than sleep 1
[22:13] <SpamapS> semiosis: expect fork is the way to go when your daemon behaves the way it expects.
[22:13] <semiosis> ok sounds good, i'll go the expect fork route
[22:13] <SpamapS> semiosis: glusterd is probably like the 50% or so of daemons that daemonize *before* setting up their listen socket... and so can't be used that way.
[22:14] <semiosis> heh, we'll see
[22:14] <SpamapS> semiosis: its not easy to see w/o reading the code
[22:14] <semiosis> ok
[22:15]  * SpamapS realizes that it would actually be fairly easy to write a program which determines the behavior via ptrace
[22:15] <semiosis> SpamapS: thanks for all your help, once again
[22:16] <SpamapS> semiosis: this will get simpler once jodh finishes the 'expect exit' work
[22:16] <semiosis> i'd really like to get this right and merged in to the glusterfs-server package for precise
[22:16] <SpamapS> semiosis: I'm planning on writing a MIR for gluster, so I'd love for you to get that in too. :)
[22:16] <jono> RAOF, hey
[22:16] <RAOF> jono: Yo!
[22:16] <jono> RAOF, someone posted a comment on my blog outlining some troubles with X in 12.04
[22:16] <jono> would you mind replying to help him get some useful data to you guys?
[22:16] <semiosis> SpamapS: MIR?
[22:17] <jono> he is at http://www.jonobacon.org/2012/01/24/hud-call-for-testers/#comment-419950714
[22:17] <SpamapS> semiosis: Main Inclusion Request
[22:17] <semiosis> w00t!
[22:17] <jono> RAOF, thanks in advance if you can take a look at this
[22:17] <SpamapS> semiosis: apparently some people want it to be officially supported. :)
[22:17] <RAOF> Urgh.  Because blog post comments are the *perfect* venue for bug reports :)
[22:18] <semiosis> SpamapS: i'm one of them... been contributing patches to debian to keep the latest available
[22:18] <semiosis> SpamapS: this upstart job is the finishing touch imho
[22:18] <SpamapS> semiosis: we'll also be putting CEPH in main, so it will be a distributed block/file store shoot-out for 12.04 users. :)
[22:19] <semiosis> yay
[22:19] <SpamapS> semiosis: if expect fork is not appropriate, is there a command you can run to sort of 'ping' glusterd to know that it is up?
[22:19] <jono> RAOF, well, I know, but I asked him for a bug
[22:20] <RAOF> Yeah, I see.
[22:20] <semiosis> SpamapS: not totally sure
[22:20] <jono> I figured you might be able to help him to get some data into a bug report that might be useful
[22:20]  * jono hugs RAOF
[22:20] <semiosis> SpamapS: if it is bound to tcp/24007 that's probably enough
[22:22] <RAOF> jono: Replied.
[22:22] <jono> thanks RAOF
[22:22] <jono> :-)
[22:26] <stgraber> nicHul8
[22:26] <semiosis> oops
[22:26] <stgraber> yeah...
[22:26] <stgraber> good thing that was a VM login prompt ;)
[23:01] <TheMuso> @pilot in
[23:13] <poolie> RAOF, hi,
[23:13] <RAOF> poolie: Hi
[23:13] <poolie> hi, i've just put x-staging back on, and external monitors are no better
[23:14] <poolie> specifically, they don't crash, but they don't set the right resolution
[23:14] <poolie> i guess that may be more of a kernel thing not x
[23:14] <poolie> is there anything i can do to help debug or solve it?
[23:14] <poolie> i guess maybe run kernel tip
[23:16] <RAOF> poolie: x-staging is now in Precise, so will no longer be helpful.  It's entirely possible that you're seeing a kernel problem; the kernel mainline builds of drm-intel-next are the things which will be most interesting there.
[23:17] <poolie> is there a ppa-ish for that?
[23:21] <poolie> nm i have http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/
[23:21] <RAOF> Oh, sorry.  Missed your question.
[23:21] <RAOF> Yeah, that's it.