[00:14] <DasEi> I understand from what I've found about the idea behind unity, though think just from clickNfeel it's a longer way to find desired app or action. What I like to know, is there a comprehensive guide or howto on how to adapt unity to ones daily needs ?
[02:08] <psusi> if the system hangs within an instance of qemeu, how can you send a magic sysrq key to the emulator and not the host?
[02:10] <Keybuk> psusi: yes
[02:11] <Keybuk> psusi: C-A-2 for the monitor
[02:11] <Keybuk> send break
[02:11] <Keybuk> or sendkey break
[02:11] <Keybuk> something like that
[02:12] <Keybuk> C-a b might do it too
[02:20] <psusi> Keybuk, hey.. I been meaning to ask you... are you still maintaining the upstream ureadahead?  because you're the only one with upload rights to lp:ureadahead
[02:23] <psusi> hrm.. those keys don't seem to do anything
[03:13] <psusi> man that is fubar... trying to create 16 logical partitions in qemu with either 10.10 or 11.04 makes the system to completely wonky, sometimes refusing to accept more mouse input, sometimes crashing Xorg... is there a channel for qa testers?
[05:02] <ohsix> hm, oregano has an untranslated string in _english_, the online translation stuff won't let me correct it
[05:02] <ohsix> the "test clamp" should say something about an instrument probe, but it says "Punte de Prueba" in the english translation
[05:05] <SpamapS> Point of Test
[05:05] <SpamapS> :)
[05:05] <SpamapS> Prueba is definitely one word that sticks from my high school spanish.
[05:12]  * SpamapS gets out the really big pointy stick to show the erlang merge he means business
[05:13] <ScottK> ohsix: oregano is in Universe, so it's translations aren't done in Launchpad.
[05:20] <SpamapS> hmm.. I wonder if the upstart->dbus->plymouth bridge shows instances... wait-for-state needs a very carefully crafted description.
[05:26] <ScottK> SpamapS: Would you please push boost-mpi-source out of binary New?
[05:26] <ScottK> I need it for a merge I'm working on.
[05:27] <SpamapS> ScottK: I'm not allowed to do full archive admin yet. :/
[05:27] <ScottK> Oh.  I saw you in the team and assumed.
[05:27] <ScottK> No problem.
[05:27] <ScottK> I should go to sleep anyway.
[05:27] <SpamapS> ScottK: cjwatson and pitti were too busy w/ the release to train me yet
[05:27] <SpamapS> ScottK: btw, sorry I couldn't help w/ the opendkim thing.. its really, really confusing why it doesn't work.
[05:28] <ScottK> Perhaps one of them will read the scrollback and take care of it while we are sleeping ...
[05:28] <SpamapS> ScottK: they do seem to have magical powers that way. :)
[05:34] <pitti> Good morning
[05:36] <RAOF> Good morning pitti
[05:37] <pitti> ScottK: seems someone already NEWed boost in the meantime?
[05:38] <ScottK> pitti: No.  It's in binary New https://launchpad.net/ubuntu/oneiric/+queue?queue_state=0&queue_text=boost
[05:38] <ScottK> (armel binary is missing due to the general armel breakage)
[05:39] <pitti> oh, I was looking at the wrong page, sorry (missed that there are several)
[05:40]  * pitti cleans up the queue
[05:41] <ScottK> No problem.   Thanks for looking into it.
[05:42] <broder> that was...impressively magical :)
[05:46] <abhinav-> pitti: if you have time then about bug 772336 , I just want to know if dependency on python-wnck is ok ? and how to attach the screenshot with the rest of the data that apport collects for creating the report ?
[05:48] <pitti> abhinav-: we can't use python-wnck, it needs to use GI I'm afraid (it's both obsolete, and it's also very crash prone to use static and GI bindings in the same program)
[05:48] <pitti> abhinav-: i. e. we want to use gir1.2-wnck-3.0
[05:48] <abhinav-> pitti: hm I don't know how to use GI :(
[06:12] <pitti> ScottK: boost NEWed; I also cleaned the binNEW from Debian syncs, so the queue is back from 144 to 5 now
[06:12] <ScottK> pitti: Thanks.
[06:36] <abhinav-> pitti: how can I look what are all the methods provided in gir1.2-wnck-3.o ?
[06:37] <pitti> abhinav-: https://live.gnome.org/PyGObject/IntrospectionPorting documents the new way of doing things
[06:37] <pitti> abhinav-: in short, just use the C API documentation
[07:04] <abhinav-> pitti: thanks! that was easy :) . I also did "import gtk" and "from gtk import gdk" , they also need to be changed for GI ?
[07:05] <pitti> abhinav-: right; but apport-gtk already has them
[07:05] <abhinav-> oh ok :)
[07:26] <Laibsch> geser: Thank you for the idea to install the packages into the base.tgz.  I guess it's still pretty weird they weren't pulled in on their own, but at least I was able to recompile grub now.
[08:34] <Sweetshark> doko_: ping?
[08:48] <abhinav-> pitti: are we using gdk 3.0 for apport ?
[08:49] <pitti> abhinav-: not in natty, but we will use gtk3/gdk3 for all our pygi stuff in oneiric
[08:49] <pitti> abhinav-: you can already run the natty versino with gtk 3, it will just look a bit ugly due to the missing theme
[08:49] <abhinav-> hm I am not sure, but it seems like doing "from gi.repository import gdk" is using gdk 3.0
[08:49] <pitti> abhinav-: in /usr/share/apport/apport-gtk (or you local checkout), just drop this line:
[08:49] <pitti> gi.require_version('Gtk', '2.0')
[08:50] <pitti> abhinav-: it's "import Gdk", BTW
[08:50] <abhinav-> ah yes
[08:50] <pitti> abhinav-: yes, it will take the latest version which is installed, unless you set it with require_version
[08:50] <abhinav-> alright :)
[09:49] <lucidfox> uuuuuugh, Unity
[09:50] <lucidfox> my first problem after updating my coworker's machine to Ubuntu 11.04 was how to revert to the classic desktop...
[09:52] <pitti> without even let him try it for a bit?
[09:56] <tjaalton> is there a way to change the desktop with just one hand (on unity)?
[10:01] <doko> janimo: did you rebuild apt with old curl?
[10:02] <janimo> curl?
[10:02] <janimo> no, was that mentioned somewhere?
[10:02] <janimo> I built in uptodate oeiric
[10:03] <doko> hmm, ok, some dependencies not fulfilled
[10:08] <janimo> doko,  how do you run the testsuit of eglibc? Are the failures in the bugreport only from build logs?
[10:10] <pitti> doko: sid's new libgc has no mention of GC_TEST_AND_SET_DEFINED or any of the other code that you patched in 1:6.8-1.2ubuntu1 (lucid); want me to sync it, and we'll see how it goes on armel, or do you want to test this manually?
[10:10] <pitti> doko: (it's on my merge list as I touched it for a no-change rebuild)
[10:11] <doko> pitti: not my priority at the moment. maybe check with the arm porters? ;)
[10:11] <doko> janimo: debian/rules check should be enough
[10:18] <pitti> ogra: ^ see my question to doko -- the patch needs to be completely redone anyway, so should we just try with the Debian version for now?
[10:20] <janimo> doko, what is the best way to switch between multiple gcc versions?
[10:22] <doko> janimo: you mean test builds? probably separate chroots
[10:27] <doko> mvo: still no verbose build in apt by default :-/
[10:27] <janimo> doko, no, in the live system. I now use symlinks, but something like update-alternatives would be nicer
[10:27] <doko> and no parallel build
[10:28] <doko> janimo: CC= CXX= are your friends for this
[10:28] <janimo> doko, I get a link error in make check in eglibc, but no test result outputs
[10:28] <janimo> tst-cancel24.o:(.ARM.extab+0x0): undefined reference to `__gxx_personality_v0'
[10:28] <doko> alternatives for api incompatible stuff just calls for trouble
[10:29] <doko> hmm, strange
[10:29] <janimo> doko, not chroot though, I'll try that next I guess
[10:32] <ogra_> pitti, just sync ... we have 6 months :)
[10:32] <doko> janimo: yesterday I did a eglibc test rebuild in oneiric, without problems
[10:39] <tumbleweed> doko: can we get --whole-archive linking in python2.7 in Ubuntu? (I assume it's already in your todo list, but making sure :P )
[10:41] <mvo> doko: sorry, comited a fix for this to bzr now
[10:45] <pitti> ogra_: ack
[10:53] <Laney> is process-removals (or the correct name) not run any more?
[11:01] <slangasek> Laney: it's been run very intermittently - we need to go back and do a complete run, I have a tendency to only remember the problem during freezes so thanks for the reminder
[11:02] <Laney> slangasek: Yes, I'd appreciate that especially as I very often forget to file corresponding LP removals after doing ftp.d.o ones
[11:02] <Laney> just discovered some retro mono packages kicking around in Ubuntu
[11:04] <slangasek> yeah, there's a lot of really old stuff in there still :(  I'll take a look at it in the morning
[11:05] <Laney> thanks
[11:34] <abhinav-> pitti: there is a problem. in Gdk 3.x they have replaced GdkRegion with cairo_region_t and thus I need to use cairo_region functions . is there a gir module for cairo ?
[11:34] <yofel> stgraber: re kdebase-workspace branch: If you want to update any other Vcs entries, they're owned by kubuntu-packagers, not kubuntu-uploaders
[11:35] <yofel> (I fixed that for workspace already)
[11:47] <Laney> hrw: barry: you might wish to add yourself to https://blueprints.edge.launchpad.net/ubuntu/+spec/other-o-dmb-meeting to please the scheduler
[11:49] <Quintasan1> jcastro: ping
[11:49] <Laney> jelmer: ^^^ you too (hopefully we'll get that far :-)
[11:55] <barry> Laney: done, thanks
[11:55] <Laney> np
[12:31] <jelmer> Laney: thanks, done
[12:49] <pitti> abhinav-: I think cairo only has static bindings for the moment
[12:49] <pitti> python-gobject-cairo
[12:51] <abhinav-> pitti: in Gdk2.x there is a method Gdk.region_rectangle but it has been completely removed in 3.x
[12:51] <abhinav-> pitti: so I should do "import cairo" ?
[12:53] <pitti> abhinav-: I don't know what it got replaced with, but if it's cairo, then sure
[12:54] <doko> mvo: do you have any changes pending for an apt upload?
[12:54] <abhinav-> pitti: yes, people at #gtk+ told that GdkRegion got replaced with cairo_region_t
[12:54] <mvo> doko: let me check
[12:55] <doko> mvo: please upload a version with a temporary b-d on gcc-4.6 (>= 4.6.0-6ubuntu2)
[12:58] <mvo> doko: ok
[13:48]  * abhinav- is frustrated with cairo :( 
[14:12] <stgraber> yofel: oops, not sure why I updated this one after ScottK pointed me to the right one ... sorry
[14:22] <jcastro> Quintasan: pong
[14:27] <Quintasan> jcastro: ahhh, mind if I go on /msg?
[14:38]  * lucidfox looks at the heap of old packages on REVU :(
[14:40] <lucidfox> I'm tempted to just mass-reject all REVU packages before mid-2010, because seriously, every time I actually go there with the intent to review packages, the mass of those old ones makes me panic
[14:40] <tumbleweed> is this not a sign that REVU isn't working?
[14:41] <lucidfox> Well, some packages from it do get uploaded, it's just that people allow it to get covered in cobwebs and dust...
[14:43] <tumbleweed> a problem is that without active maintainence, packages die. And lots of packages in REVU look like they might be drive-by submissions. I tend to suggest Debian for new packages where appropriate...
[14:44] <ScottK> lucidfox: I'm OK with that.
[14:45] <lucidfox> Well, it's a vicious cycle. Packagers submit packages, reviewers don't review because of the long queue stretching back to two years ago, packagers lose interest and stop updating, reviewers archive packages and forget about them
[14:45] <lucidfox> and yes, I found Debian's ITP more responsive most of the time
[14:46] <tumbleweed> another problem is the release cycle. Packages really should get accepted before feature freeze, but I don't know how many submitters are aware of the schedule
[14:46] <doko> pitti, Sweetshark: re-openened the ooo-langpacks spec
[14:49] <rohan> hi.. i am trying to know how a livecd upgrade (introduced in 11.04) works.
[14:49] <rohan> I asked in #ubuntu but that channel is too noisy -- sorry for butting in here
[14:50] <cjwatson> ev: ^-
[14:50] <ev> rohan: I posted about this on ubuntu-devel-announce: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-April/000841.html
[14:51] <rohan> oh, i could have sworn that i was subscribed to ubuntu-devel-announce..
[14:52] <rohan> thanks a lot, cjwatson , ev :)
[14:52] <ev> sure thing
[14:52]  * cjwatson tries to get merges.u.c to actually update
[14:53] <cjwatson> mysterious 404s while updating the pool
[14:57] <Sweetshark> doko: pitti and I skimmed through the exsisting blueprints, which is why this was closed. IMHO the solution would be http://wiki.documentfoundation.org/Development/Gsoc/Ideas#Translations_using_gettext and blueprints desktop-o-libreoffice and desktop-o-libreoffice-communities vaguely refer to that.
[16:02] <lynxman> ping pitti
[16:06] <kirkland> cjwatson: pitti: what creates /etc/hosts during installation?
[16:09] <ScottK> slangasek: I'm starting to suspect that Bug #769514 is somehow multi-arch/chroot related too.  All the Postfix config files I've reviewed offline look correct.
[16:09] <ScottK> My suspicioun is /etc/services in the chroot isn't being read.
[16:09] <cjwatson> kirkland: netcfg
[16:09] <kirkland> cjwatson: cool, thanks
[16:09] <ScottK> (just imagine I spelled that better)
[16:09] <kirkland> lynxman: ^
[16:10] <lynxman> kirkland: gotcha
[16:10] <kirkland> cjwatson: there seems to be some situation in server and/or cloud installs that ends up with an /etc/hosts file missing the 127.0.1.1 $hostname entry
[16:10] <kirkland> lynxman: investigating and solving that will be best in the long run
[16:11] <lynxman> kirkland: definitely, will have a quick look, thanks :)
[16:11] <kirkland> lynxman: as for the cloud installs, check with smoser
[16:11] <kirkland> lynxman: it might be something he needs to add to either cloud-init, or to his image build scripts
[16:11] <lynxman> kirkland: that I think has a solution already
[16:11] <kirkland> lynxman: oh?
[16:11] <lynxman> kirkland: cloud-init has the otion to address it
[16:12] <lynxman> kirkland: you have an option in cloud-init were you can let cloud-init manage /etc/hosts using a template
[16:12] <kirkland> lynxman: i see
[16:13] <cjwatson> kirkland: by design, you only get 127.0.1.1 if you haven't configured a better static address
[16:13] <cjwatson> that's the sole condition involved here
[16:13] <kirkland> cjwatson: oh, interesting;  lynxman -- is that the situation you're encountering?
[16:13] <lucidfox> Is there a way to print a list of all source packages known to apt?
[16:13] <lynxman> cjwatson: the problem we're seeing is that on default cloud installs there's no entry in /etc/hosts that matches hostname
[16:14] <cjwatson> netcfg always writes out such an entry.  I don't know what cloud-init does to it
[16:14] <lynxman> cjwatson: so we got an IP and a generated hostname delivered by the metadata service, but then no entry in /etc/hosts shows up
[16:15] <lynxman> cjwatson: same for cobbler, it gets IP and hostname, but no entry in /etc/hosts either
[16:17] <cjwatson> lynxman: I don't see anything in netcfg that could cause that.  you sure it isn't a cloud-init problem?
[16:18] <cjwatson> (which is not a package I know anything about)
[16:18] <lynxman> cjwatson: cloud-init is not in play on this, I can solve it through cloud-init overwriting /etc/hosts but on a default install that's an issue
[16:19] <cjwatson> lynxman: well, give me /var/log then
[16:19] <cjwatson> and /etc/hosts
[16:19] <lynxman> cjwatson: sure, gimme 2 ticks
[16:30] <lynxman> cjwatson: got everything, email is fine?
[16:31] <cjwatson> lynxman: sure
[16:42] <psusi> cjwatson: I have a server I just upgraded to natty and grub is puking on the raid5 claiming it is seeing multiple disks with the same id, and more disks than the array is supposed to contain.  I suspect this is because of the changes to recognize the new md superblock formats and grub is detecting the superblock both in the whole disk, as well as in the partition ( single raid partition ).  Any ideas on how to test that theory?
[16:44] <cjwatson> lynxman,kirkland: this isn't a d-i install, nor ubiquity.  cloud-init is doing it all itself.  not my problem ...
[16:45] <cjwatson> lynxman,kirkland: I assume it does its own debootstrap and fills things out from there.
[16:45] <cjwatson> lynxman: if you want me to investigate a problem with the standard server installer, I'll need logs from a system that was actually installed with the standard server installer :)
[16:46] <lynxman> cjwatson: fair enough :)
[16:46] <cjwatson> psusi: hm, there were a few changes in 1.99~rc2 that might address that
[16:47] <lynxman> cjwatson: I'll look more into the problem, thanks
[16:48] <cjwatson> psusi: e.g.:
[16:48] <cjwatson> 2011-04-06  Vladimir Serbinenko  <phcoder@gmail.com>
[16:48] <cjwatson>         * grub-core/disk/mdraid1x_linux.c (grub_mdraid_detect): Detect spares
[16:49] <cjwatson>         and report them as not RAID members since they are useless for GRUB.
[16:49] <cjwatson>         * grub-core/disk/mdraid_linux.c (grub_mdraid_detect): Likewise.
[16:50] <cjwatson> psusi: I'll be merging 1.99~rc2 into Debian and Ubuntu at some point over the next week or so, I think (I'm doing some fairly large packaging changes at the same time); once I've done that, it might be worth trying that, though I don't know how much time I have
[16:50] <kirkland> cjwatson: thanks, no problem, we'll take it up with smoser
[16:50] <psusi> hrm... I'll give it a try... though I don't have any spares... just 4 disks each with a single raid partition
[16:50] <cjwatson> er, *how much time you have
[16:51] <cjwatson> there's also "Identify RAID by its UUID rather than (guessed) name."
[16:52] <psusi> cjwatson: I should pull from lp:grub/grub2?
[16:52] <cjwatson> psusi: yeah, though the patch resolution will be tricky
[16:53] <cjwatson> psusi: which superblock format are you using?
[16:53] <psusi> cjwatson: hrm... I would say 0.9 but I'm not sure if that is still the default.. was the default changed in maverick?  I built the array with d-i when installing maverick...
[16:54] <Quintasan> urgh, how do I install grub from live cd?
[16:54] <Quintasan> I get /usr/sbin/grub-probe: error: cannot stat `aufs'.
[16:54] <cjwatson> psusi: the default was changed a while back.  check /proc/mdstat
[16:54] <cjwatson> Quintasan: chroot
[16:54] <Quintasan> cjwatson: can't do that, claims /dev is not mounted
[16:54] <cjwatson> Quintasan: bind-mount it (and /proc and /sys)
[16:55] <cjwatson> (you certainly can do it, I do it all the time)
[16:55] <cjwatson> https://help.ubuntu.com/community/Grub2#METHOD%203%20-%20CHROOT
[16:55] <Quintasan> uhmm
[16:55] <Quintasan> something is strage here
[16:55] <Quintasan> cjwatson: I mounted my / under /mnt when on livecd
[16:56] <Quintasan> and I have "@" directory
[16:56] <Quintasan> is this normal?
[16:56] <cjwatson> Quintasan: yes, you're using btrfs
[16:56] <cjwatson> mount -o subvol=@
[16:57]  * ogra_ wonders why nilfs2 rootfs'es dont work :(
[16:57] <psusi> cjwatson: actually it has to be 0.9 since grub in maverick did not understand any other formats didn't it?
[16:57] <RoAkSoAx> /query/win 22
[16:57] <RoAkSoAx> argh
[16:57] <ogra_> i added a hook script to copy all the mount.nilfs2 and umoun.nilfs2 bits ... but the initrd still dies
[16:58] <cjwatson> psusi: maverick would have been 0.9, yes
[16:59] <cjwatson> psusi: however, the maverick installer forced some unpartitioned space at the end of the disk to account for this problem
[17:00] <cjwatson> (lucid as well)
[17:00] <cjwatson> at least it was supposed to
[17:01] <psusi> I'll check and make sure that's there and try building a grub rescue cd from lp:grub/grub2 then
[17:03] <cjwatson> psusi: grub-probe has a -vv option that may help too
[17:05] <lucidfox> Hmm, maybe I should write a "common REVU rejection reasons" or "REVU submission checklist" page
[17:06] <Quintasan> cjwatson: Thanks!
[17:10] <Quintasan> ...
[17:10] <Quintasan> oh wait, now I get Geom Error
[17:10] <cjwatson> Quintasan: that's a GRUB Legacy error ...
[17:10] <cjwatson> wait, no it isn't
[17:11] <Quintasan> magic
[17:11] <Quintasan> I didnt do anything except that chroot stuff
[17:11] <cjwatson> does your BIOS not support LBA?
[17:12] <Quintasan> no idea, it's an Acer Extensa 5220 laptop
[17:13] <cjwatson> well, that error is CHS-specific I think
[17:13] <cjwatson> it might be easier to tweak the BIOS setup to use LBA than to figure out why GRUB is breaking with CHS
[17:13] <Quintasan> cant find any LBA in BIOS setup
[17:14] <cjwatson> ironically, this error is documented in the GRUB Legacy info doc but not in GRUB 2
[17:14] <cjwatson> http://paste.ubuntu.com/602863/
[17:14] <cjwatson> are you trying to install to a partition?
[17:15] <psusi> cjwatson: yep, it is 0.9 with some free space at the end of the disk... mdadm -E doesn't find the superblock on sda either, just sda1.  guess that was a wrong guess...
[17:15] <Quintasan> cjwatson: I did update-grub after chrooting, it was probably stupid of me to do so when grub could have not gotten installed
[17:15] <cjwatson> psusi: or of course it's possible I didn't leave enough space
[17:15] <cjwatson> Quintasan: are you trying to install to a partition?
[17:16] <Quintasan> cjwatson: no idea, in graphical installer I pointed to install on /dev/sda
[17:16] <cjwatson> Quintasan: this error is before GRUB manages to read the output of update-grub
[17:16] <cjwatson> Quintasan: did you run 'grub-install /dev/sda' inside the chroot?
[17:16] <Quintasan> nope
[17:16] <cjwatson> you didn't reinstall GRUB then ...
[17:19] <Quintasan> cjwatson: warn: Your core.img is unusually large. It won't fit in the embedding area...
[17:20] <Quintasan> Later it says it can install by blocklists but they are unreliable
[17:24] <cjwatson> Quintasan: yeah, particularly for btrfs.  I don't suppose it would be possible to move your first partition to the now-more-standard practice of starting 1MiB into the disk rather than 63 sectors in?
[17:24] <cjwatson> Quintasan: we are going to implement a special embedding method for btrfs, but it's not in natty
[17:24] <Quintasan> cjwatson: can I do it without reformatting anything?
[17:24] <cjwatson> and GRUB's core.img with btrfs is indeed too large for first-partition-at-63-sectors (bug 774217)
[17:25] <cjwatson> Quintasan: gparted should be able to, although you should take backups first
[17:25] <cjwatson> sorry this is awkward, as noted in the release notes btrfs is still experimental, and that goes for the distro integration too ...
[17:26] <Quintasan> cjwatson: That's why I wanted to test it :D
[17:29] <cjwatson> Quintasan: I've release-noted 774217 now
[17:29] <Quintasan> cjwatson: 1 MiB will be enough?
[17:29] <cjwatson> easily
[17:30] <Quintasan> I don't have anything valuabe apart from Windows install there so I can experiment more if you want me to :P
[17:30] <cjwatson> it's only about 1KiB over the limit
[17:41] <Who__> cjwatson: There are now logs in bug https://bugs.launchpad.net/ubuntu/+bug/774089 as you requested
[17:42] <Who__> cjwatson: but as yet no good way to install Ubuntu without requiring reflashing the firmware to the motherboard
[17:49] <cjwatson> Who__: "Why does the installer even touch the firmware" - dubious axiom detected :)
[17:50] <cjwatson> grub-install uses efibootmgr, maybe that's busted or being invoked wrongly
[17:50] <cjwatson> AFAIK that's the only place we go near the firmware
[17:51] <Who__> cjwatson: :) true, true. How about. "How does installing ubuntu on the hard disk cause a problem with the firmware"?
[17:52] <Who__> cjwatson: Is the use of efibootmgr new? (ie did it happen in 10.10?)
[17:53] <Who__> cjwatson: and thanks for looking at this
[17:55] <cjwatson> Who__: it goes back to maverick, though details may have changed
[18:00] <lucidfox> http://revu.ubuntuwire.com/p/gmailwatcher
 Good grief, just how many gmail notifiers does the Ubuntu archive need?
 cgmail, checkgmail, gm-notify, gmail-notify, gnome-gmail-notifier, kgmailnotifier, kcheckgmail, and also gmail-notifier and gmailwatcher in proposed packages
[18:05] <slangasek> ScottK: 769514> yes, service name resolution is also done via nss_files :/
[18:06] <ScottK> slangasek: There's a proposed patch in the first one I pointed you to, so that's something.
[18:06]  * slangasek nods
[18:06] <slangasek> the patch needs finessing to get the right arch string at build time, but yeah
[18:08] <ScottK> Would that solve this new one as well then?
[18:08] <slangasek> yes
[18:08] <ScottK> Excellent.
[18:08] <ScottK> I'd appreciate it if you could make fixing this a priority.
[18:09] <slangasek> yes, I think I can get that done today
[18:10] <ScottK> Great.  Thanks.
[18:12] <kirkland> jjohansen: howdy
[18:12] <jjohansen> kirkland: hey
[18:12] <kirkland> jjohansen: are you still planning on completing the ecryptfs-long-filename work for Oneiric?
[18:13] <jjohansen> kirkland: yep /meneeds to get back to it
[18:13] <kirkland> jjohansen: i don't think we necessarily need a UDS session about it, but perhaps just having a (or moving the natty)  blueprint for Oneiric would be nice
[18:13] <kirkland> jjohansen: yeah, i think you were pretty close for Natty
[18:13] <jjohansen> hrmm, right
[18:13] <kirkland> jjohansen: would be nice to get that one front loaded
[18:14] <jjohansen> well I would say its pretty far atm, the dentry file is a fair bit more work
[18:14] <jjohansen> of course we can leverage a lot of what has been done
[18:14] <jjohansen> kirkland: I will move the bp forward
[18:15] <kirkland> jjohansen: sweet
[18:15] <kirkland> jjohansen: well, sweet to the latter
[18:15] <kirkland> jjohansen: bummer about the former
[18:15] <jjohansen> heh, yeah
[18:26] <psusi> cjwatson: I notice there is a dprint in there every time a raid member is registered... how do you enable that output?
[18:32] <cjwatson> psusi: 'set debug=raid' (first arg to grub_dprintf) or 'set debug=all'
[18:33] <psusi> cjwatson: any way to set that before the built in raid module is initialized?  or force it to reinitialize after setting it?
[18:34] <cjwatson> grub-install --debug-image=raid or --debug-image=all
[18:35] <cjwatson> (the latter will produce a *lot* of output)
[18:38] <psusi> cjwatson: also I tried to ./grub-mkrescue up a bootable iso in the build directory of the upstream grub and it apparently built an empty iso... can it not work out of the build tree?  Does it have to be installed?
[18:41] <psusi> hrm... since I'm building a bootable cd I can't use grub-install right?  any way to set that with mkrescue?
[18:52] <smoser> kirkland, around ?
[18:52] <kirkland> smoser: howdy
[18:52] <smoser> i can give insight to the cloud-init /etc/hosts issue if you want.
[18:53] <ohsix> ScottK: shrug, i looked at it and there were translations on there with various levels of completion, just not english
[18:53] <smoser> cloud-init does not write /etc/hosts 127.0.1.1 entry by design.  that was so that it could avoid updating it, and dealing with overwriting user changes on subsequent "rebundles".
[18:53] <ScottK> ohsix: Yes, but they are in the package itself, not part of the Launchpad translations system.
[18:54] <kirkland> smoser: hmm
[18:54] <smoser> instead it stays out of the way entirely.  Unless (in natty) you tell it to manage hosts.
[18:54] <smoser> https://bugs.launchpad.net/cloud-init/+bug/768296 has more information
[18:54] <smoser> on how to do that.
[18:55] <kirkland> smoser: okay, i've subscribed lynxman to that bug;  he's the one having issues with this
[18:55] <kirkland> smoser: i'm trying to help him work around it
[18:56] <Who__> cjwatson: I don't have my machine back yet but if nobody has replied with more info (re: your comment on the bug) by the time I do have it, I'll put the logs up :)
[18:56]  * slangasek gets rid of all the stale packages in oneiric that were removed from Debian in 2009 :(
[18:57] <cjwatson> psusi: it can work from the build tree, but it takes a few options.  ./grub-mkrescue --grub-mkimage=./grub-mkimage --override-directory=grub-core -o grub.iso
[18:57]  * micahg hugs slangasek for the archive cleanup
[18:57] <Laney> \o/ thanks slangasek
[18:57] <smoser> lynxman, bug 407861 is some history on that.
[19:04] <chrisccoulson> SpamapS, there?
[19:20] <SpamapS> chrisccoulson: here now, whats up?
[19:21] <chrisccoulson> hi SpamapS. i'd like to get your thoughts on my comments at the end of bug 548866
[19:22] <chrisccoulson> basically, the fix for that is contributing to quite a serious and fairly widespread bug in natty
[19:28] <SpamapS> reading
[19:30] <SpamapS> chrisccoulson: +1 , High trumps Low even when it means regressing an already fixed Low.
[19:31] <chrisccoulson> SpamapS, cool, thanks. i'll get this prepared and upload to natty-proposed in a bit then, once i've done some testing
[20:30] <quadrispro> hi all
[20:45] <pitti> doko: reopened ooo-langpacks> oh, why?
[20:46] <pitti> kirkland: /etc/hosts> I don't know, I'm afraid
[21:05] <jcastro> ScottK: your tracks are all set now? any issues?
[21:06] <ScottK> jcastro: No issues.  I think it's all good.
[21:06] <ScottK> If any problems come up, I'll just move server sessions out of the way.
[21:06] <jcastro> heh
[21:19] <psusi`> cjwatson: that version of grub has the same problem.  Also looking at the raid debug messages, it is NOT trying to recognize the member more than once; it complains about the duplicate ID the very first time it is scanned when loading mdraid09.mod
[21:29] <Laney> ScottK: Is there any way you can move "Discuss Ubuntu Backports" earlier? I unfortunately have to fly at 1850 on Friday and so likely won't be able to make that time.
[21:29] <Laney> I set my time on Launchpad but it still scheduled it then
[21:29] <ScottK> Laney: I am not supposed to move those.  We need to ask slangasek.
[21:30] <Laney> OK
[21:30] <Laney> I guess we just did
[21:30] <ScottK> Hopefully.
[21:31] <SpamapS> Yeah I'd like to discuss that much earlier in the week
[21:31] <slangasek> so, Monday?
[21:31] <SpamapS> It will affect SRU discussions somewhat
[21:32] <SpamapS> Monday would be awesome.
[21:32]  * ScottK is pretty booked on Monday already.
[21:33] <SpamapS> ScottK: where are you at 16:15 ?
[21:33] <Laney> does it matter if it's before or after the ui session? expecting any overlap?
[21:33] <Laney> 1615 is bad: DMB meeting
[21:33] <SpamapS> 15:00 ?
[21:33] <slangasek> er, actually, that was dumb of me
[21:33] <ScottK> Postfix package improvements
[21:33] <ScottK> SpamapS: ^^^ you want to be there too.
[21:34] <SpamapS> slangasek: hah.. asking, right.. just tell us. :)
[21:34] <slangasek> Laney: mark yourself as essential participation for the blueprint and record your hours of UDS availability; the autoscheduler will probably do a much better job of resolving the conflict than we will
[21:34] <ScottK> I could stand to do the last session of the day.
[21:34] <Laney> slangasek: I did already
[21:34] <slangasek> SpamapS: no, I mean, it was dumb of me to unschedule the session
[21:34] <Laney> didn't I?
[21:34] <slangasek> Laney: right, I see that now
[21:34] <slangasek> Laney: I think the system hadn't refreshed yet
[21:35] <psusi> cjwatson: nevermind, my eyes must have glazed over... looked at it again and indeed it is scanning and detecting the superblock on both hdx and hdx,msdos1
[21:35] <slangasek> shows a sched conflict now
[21:35] <SpamapS> ScottK: yes I do. :) I forgot to do the hostname apport hook in natty, need to get that done. :)
[21:35] <Laney> cool
[21:35]  * Laney is sad to have to miss the wrap up and party
[21:35] <ScottK> slangasek: How about 17:05 on Monday.
[21:35] <ScottK> I can probably get more volunteers for stuff when they're tired.
[21:36] <slangasek> ScottK: done
[21:36] <cjwatson> psusi: I guess I must have got the partitioning constraints wrong; independent of whatever's going wrong with grub, that would be a bug on partman-base ...
[21:36] <ScottK> Laney: ^^^ There you go.
[21:36] <Laney> looks good to me
[21:36] <Laney> thanks
[21:37] <cjwatson> psusi: do you have a screenshot or something of the debug messages?
[21:44] <psusi> cjwatson: it is the found array one immediately after the scanning for raid devices on... then the scanning on repeats for the ,msdos1 where you get the found two disks with the index one
[21:44] <cjwatson> psusi: screenshots are loads easier to deal with than paraphrases
[21:44] <psusi> for obvious reasons... how much space should be reserved? it was enough in maverick and it looked like a few thousond sectors when I checked earlier
[21:45] <cjwatson> md(4) says: "The common format — known as version 0.90 — has a superblock that is 4K long and is written into a 64K aligned block that starts at least 64K and less than 128K from the end of the device (i.e. to get the address of the superblock round the size of the device down to a multiple of 64K and then subtract 64K)."
[21:45] <cjwatson> so it needs to be enough to make the superblock unambiguous
[21:46] <psusi> so at least 128k from the end of the disk is where the partition should end?
[21:46] <cjwatson> 64K should be enough, given that description (since the superblock will be at least 64K before that)
[21:57] <LLStarks> slangasek, robbiew proposed a new blueprint for debdelta yet i don't think foundations will be discussing it uds. is the debdelta blueprint dependent on how its gsoc project for debian goes?
[21:58] <psusi> cjwatson: yep, 369 sectors between the end of the partition and the end of the disk...
[21:59] <slangasek> LLStarks: we intended to put it on the agenda for UDS for foundations to discuss it, yes - but anything we implement for this cycle is almost certainly going to be dependent on the GSoC project
[21:59] <slangasek> LLStarks: did you mean this one registered by cjwatson (not robbiew), or another? https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-debdelta
[22:00] <LLStarks> yup
[22:01] <LLStarks> that's the one, robbiew had mentioned a new proposal in the now-defunct apt-sync proposal
[22:01] <LLStarks> heck, that's the first time i'm seeing that proposal because it's brand new
[22:02] <LLStarks> i was going through the uds schedule yesterday and saw nothing about footprint or debdelta
[22:05] <cjwatson> psusi: should be plenty.  maybe there's a stale superblock lying around at the end?
[22:05] <cjwatson> LLStarks: I think the relevant things from our side will be dealing with whatever Ubuntu-specific infrastructure is required
[22:06] <LLStarks> sounds good. is is oneiric or oneiric+1 lts the target?
[22:08] <LLStarks> nvm
[22:09] <psusi> cjwatson: I guess I could try poking around a bit manually, but mdadm -E doesn't see it and neither did maverick's grub...
[22:14] <ScottK> slangasek: This (debdelta) reminds me ...  It seems like it's been quite awhile since the state of the dbgsym repository was discussed.  Would it be worth having a session to discuss how to better integrate it?
[22:15] <sladen> ScottK: +1
[22:15] <slangasek> ScottK: sure - whip me up a blueprint?
[22:15] <ScottK> OK.
[22:18] <ScottK> slangasek: https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-dbgsym-integration/
[22:19] <ScottK> sladen: ^^^
[22:19]  * SpamapS subscribes
[22:21] <sladen> I'll say it again though;  if zsync or debdelta or similiar are going to actually get deployed, they need to have top level management should for forcing it through because of the need to make the equivalent changes to the build and mirror infrastructure at the same time
[22:22] <LLStarks> as long as traditional debs and ppas benefit, i'm all for it.
[22:22] <LLStarks> *traditional debs can be used
[22:33] <LLStarks> dbgsym should implemented as an included repo (toggled off?) or added to the already hefty sources repos. heck, even a command to automagically add it like a ppa would be nice. it wouldn't take much more than a python script or two.
[22:34] <LLStarks> add-apt-dbgsym sourcepackagename