[00:42] <cjwatson> lifeless: believe so, it certainly had raid6 code last I looked
[00:43] <cjwatson> not sure how well-tested but I think it's been at least tried ...
[00:46] <lifeless> cjwatson: cool, thanks.
[00:46] <lifeless> cjwatson: I'll poke around, I just couldn't seem to get a clear 'should' or 'no chance' from google ;)
[01:40] <slangasek> smoser: regarding bug #1080841, what was the use case for overlayfs on /etc/init?
[02:45] <psusi> lifeless, I know it works for raid5, and there is a raid6 module as well, so I assume it works too
[02:45] <lifeless> ok cool
[02:46]  * lifeless is nearly ready to cut over his migrated home server
[02:46] <psusi> migrated?
[02:46] <lifeless> psusi: same chassis, 4 new 3TB disks in an external enclosure;
[02:46] <psusi> I was playing with grub today trying to come up with an install that has everything in the core image since with partitions being 1mb aligned these days, there's plenty of room for it... be nice to have access to everything you might need to recover from a failed boot
[02:47] <lifeless> psusi: once its all checksummed etc I'll move them inside the chassis
[02:47] <lifeless> psusi: but I'm tossing the seperate /boot
[02:47] <psusi> I have a server at work that only can boot from cd, so now that cd installs are no longer supported, recovering on it is a pain when grub fails as it did for me the other day
[02:47] <lifeless> psusi: in favour of gpt + bios boot partition
[02:48] <psusi> hrm... 3 tb?  make sure /boot partition is under 2tb
[02:48] <lifeless> the old disks are from - uhm, 2007 IIRC.
[02:48] <lifeless> psusi: no /boot at all; a ef02 partition instead
[02:48] <lifeless> psusi: thats 10MB
[02:48] <psusi> you'll need a /boot since the bios can't access past 2tb
[02:49] <psusi> or you might get it to work with the grub ata disk module to bypass the bios
[02:49] <lifeless> fallback plan is a usb stick shoved in the front :)
[02:49] <psusi> no uefi? ;)
[02:49] <lifeless> motherboard was made in 2007.
[02:50] <psusi> at least it boots from usb.. my server at work won't even do that
[02:50] <lifeless> it even has a floppy drive
[02:51] <psusi> to get it to boot I finally ended up booting the precise server cd in recovery mode, mounting the drives, and using kexec to boot the installed kernel ;)
[02:54] <psusi> but yea, watch out for the 2 tb limit... if parts of the fs needed to access the kernel and initrd are above that, you'll have a problem
[02:56] <lifeless> I thought that was a fdisk partition table limit
[02:57] <psusi> it's that too, but it is also a bios limit iirc... 32 bit lba in the extended lba bios disk call
[02:57] <psusi> afair
[02:57] <lifeless> :(
[02:57] <lifeless> will find out
[02:57] <StevenK> That's why I have a /boot as the first partition on large disks
[02:58] <psusi> hrm... time to go look up extended int 13 again
[02:59] <psusi> oh wait.. no... looks like the extended int13 is 64 bit according to wikipedia
[03:00] <psusi> though most biosen probably ignores the upper 32 bits ;)
[03:02] <psusi> lifeless, oh, and the bios_grub partition only needs to be 1MB... even when I threw everything and the kitchen sink into the grub core image today it was just a hair over 512k
[03:03] <psusi> which it turns out is too large to load in real mode ;)
[04:20] <ScottK> Sigh.  I'd appreciate any suggestions why opendkim now FTBFS?  There does not appear to be anything in the diff between the two uploades - http://paste.debian.net/234349/ - that at all relates to the build failure: https://launchpadlibrarian.net/131287010/buildlog_ubuntu-raring-i386.opendkim_2.8.0~beta4-1_FAILEDTOBUILD.txt.gz - openldap hasn't changed either.  Was there a recent change in linker behavior?
[07:01] <pitti> Good morning
[08:17] <dholbach> good morning
[08:41] <pitti> tjaalton: I was looking at https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-mutter/113/artifact/mutter.log and discussed that with upstream; they said that our libxi package is "marked as a version that supports barriers, but we reverted that feature"
[08:41] <pitti> tjaalton: is that known?
[08:41] <tjaalton> pitti: this is new mutter?
[08:42] <pitti> tjaalton: upstream git head, yes
[08:42] <pitti> PKG_CHECK_EXISTS([xi >= 1.6.99.1],
[08:42] <pitti>                  AC_DEFINE([HAVE_XI23],[1],[Define if you have support for XInput 2.3 or greater]))
[08:42] <pitti> tjaalton: it's doing that -- would it be prudent to also revert the version in the .pc while the "revert barriers" patch is applied?
[08:42] <tjaalton> we're staging the upstreamed barrier events stuff in canonical-x/x-staging, needs unity ported until it's useful
[08:42] <tjaalton> oh
[08:43] <tjaalton> yeah I accidentally uploaded the new libxi to raring
[08:43] <tjaalton> that sounds doable yes
[08:46] <pitti> tjaalton: mind if I just do that, or would that disrupt some git/bzr packaging tree?
[08:46] <tjaalton> pitti: nah just do it, I'll pull the diff if needed
[08:46] <tjaalton> need to hardcode it in xi.pc.in
[08:46] <pitti> tjaalton: ok, thanks; I don't see a .pc change in http://launchpadlibrarian.net/130564301/libxi_2%3A1.6.1-1_2%3A1.6.99.1-0ubuntu1.diff.gz , I guess it's determined from configure.ac
[08:47] <tjaalton> yep
[08:57] <happyaron> Who should I ask for NEW processing?
[09:49] <Dedunu> HI im going to fix this https://bugs.launchpad.net/hundredpapercuts/+bug/694283 so how to check installation fixes any idea?
[09:53] <caribou> what would be preferable for a debootstrap SRU patch : Merge proposal or debdiff ? I'm fine with both
[09:53] <caribou> this is for Lucid btw
[09:54] <cjwatson> caribou: don't much care but I find MPs a bit awkward for stable releases to be honest
[09:55] <caribou> cjwatson: ok, I'll attach a debdiff to the bug
[09:57] <caribou> cjwatson: btw, I had to slightly adapt your commit: yours used checksum & verify_checksum while the old version was still using md5/check_md5
[09:59] <cjwatson> Doesn't surprise me
[10:06] <Dedunu> caribou: cjwatson: so im working on papercuts
[10:07] <Dedunu> cjwatson: caribou: i want to test those after fixing
[10:10] <caribou> Dedunu: my guess is that you'll need to recreate the install media to test it, but I'm not an expert @Ubiquity
[10:10] <caribou> Dedunu: that's partly what I had  to do to test my debootstrap fix
[10:11] <caribou> Dedunu: I used https://help.ubuntu.com/community/InstallCDCustomization to rebuild my archive
[10:14] <cjwatson> with ubiquity it's easier to just boot into a live session, apply your fix to the installer (which you can generally do just with an editor since it's mostly in interpreted languages, or perhaps by scp-ing files into place), and then run the installer
[10:14] <Dedunu> caribou: cjwatson: im a starter its better to keep it away for a while
[10:14] <cjwatson> recreating the install media is usually about ten times more work :)
[10:14] <Dedunu> i think it is very easy to fix but hard to test for me
[10:14] <cjwatson> *if* you already know what you're doing
[10:15] <Dedunu> i thought recreating installation media it easy
[10:15] <caribou> cjwatson: true, I just went through that pain :-/
[10:16] <cjwatson> Dedunu: it's considerably more effort than editing a file
[10:16] <cjwatson> no matter what way you slice it
[10:16] <Dedunu> hmm
[10:16] <Dedunu> thanks guys ill look into something else
[10:16] <Dedunu> on papercuts
[10:23] <cjwatson> ntfs-3g (1:2013.1.13-1) raring; urgency=low
[10:23] <cjwatson> xnox: ^- uh, didn't you just steal a Debian version number?  please don't do that ...
[10:24]  * cjwatson anticipates future merge pain :(
[10:25] <xnox> cjwatson: yes i did.
[10:25] <xnox> =(
[10:25] <xnox> and it even has ubuntu changes, so it totally should have been -0ubuntu1
[10:25] <Laney> ruh roh
[10:26] <OdyX> tkamppeter, pitti: as you maybe saw, I uploaded cups 1.6.1-2, that you can just sync.
[10:26]  * xnox ponders about 1:2013.1.13-1+0ubuntu1
[10:29]  * xnox files a bug against bzr-builddeb
[10:37] <seb128> Riddell, hey, I just newed qtscript, only source left in the queue is qt3d ... did you start looking at this one?
[10:45] <Riddell> seb128: I've not looked at it no
[10:45] <seb128> Riddell, do you plan to today? or should I give it a try? ;-)
[10:47] <Riddell> seb128: looking at New queue is on my todo for the day but low down
[10:47] <Riddell> seb128: so either do it yourself or keep poking me to do it
[10:48] <seb128> Riddell, ok, I will get started on it then, let's see if I manage to go through this one, I will let you the other stuff in the queue then ;-)
[10:48] <pitti> OdyX: thanks!
[11:13] <mpt> m4n1sh! Long time no see!
[11:24] <syntroPi> Why is firefox still not using the system libcairo2? the integrated libcairo2 has a bug that prevents it from unsing gnome3 subpixel rendering (I have BGR monitor but only FF renders RGB rainbow fonts, very annoying to read)...?
[11:33] <shadeslayer> cjwatson: any news on updating live-build?
[11:39] <mpt> syntroPi, I think you have just explained a bug I have been suffering from for years ... For me, Firefox and Thunderbird fonts are extremely hinted, while all other apps look fine
[11:44] <syntroPi> mpt there were bugs in libcairo2 from ubuntu which caused it not to respect gnome subpixel rendering set from BGR to RGB. there was a patch for that (a switch statement had a "break;" missing) and in newest version on quantal it seems to be resolved. but thats only system libcairo2, the ff version still seems to have this bug included therefore I suspect it not to use "--enable-system-cairo"
[11:46] <syntroPi> but maybe thats for a reason since ff uses heavy patched versions of cairo2
[11:47] <Laney> Perhaps firefox's cairo could pick this other patch up then
[11:47] <syntroPi> i hope it would be integrated but im not sure im competent enough to submit such a patch
[11:58] <m4n1sh> mpt: yeah. Your mockup has been implemented and added to alm. Only if I could get the thing working. Some gtk issues and as usual autotools is acting weird
[11:58] <mpt> m4n1sh, awesome! (Took me a few seconds to work out what "alm" meant)
[11:58] <m4n1sh> oh yeah. sorry for that. I should call it privacy
[11:58] <mpt> m4n1sh, I think it would be fine for all those buttons to be square, actually
[11:59] <m4n1sh> is there a way to override the theme?
[11:59] <mpt> They aren't a radio set, or a navigation set
[11:59] <mpt> I don't know, sorry, that's more of a question for Cimi
[12:01] <m4n1sh> yeah. I think so. First I need to get that gtk issue solved. The application isn't showing the window. I know very stupid issue, but I think I made some change which broke it
[12:16] <syntroPi> someone here who knows the internals of firefox package and willing to help me with integrating a known patch to libcairo2 in it?
[12:17] <syntroPi> am currently compiling it to take a browse at the patched sources
[12:17] <syntroPi> and that thing is _HUGE_
[12:20] <seb128> syntroPi, talk to chrisccoulson
[12:23] <syntroPi> seb128, thx but i will need some time to gather all info when the compile is complete...
[12:23] <seb128> syntroPi, well, you asked "who", I just replied to that
[12:23] <syntroPi> yup
[12:40] <wookey> what is libaudit-dev for? New pam uses it and is getting in the way of my bootstrap
[12:40] <wookey> can I just turn it off? or does it need to be made to work, along with libcap-ng (which woulw need de-swiging)
[12:46] <cjwatson> wookey: -> slangasek
[12:46] <cjwatson> but from the changelog:
[12:46] <cjwatson>   * Enable audit support, by popular demand.  This should have no major
[12:46] <cjwatson>     impact unless you're also running auditd; but I reserve the right to
[12:46] <cjwatson>     disable this again in the event that this causes a performance hit or
[12:46] <cjwatson>     breaks upgrades (since the dependency is pulled into libpam, not just
[12:46] <cjwatson>     into pam_tty_audit).  Closes: #699159, LP: #937005.
[12:47] <wookey> there is a --dsiable-audit know so I shall use it
[12:47] <cjwatson> Disabling it for the bootstrap doesn't seem like it would be a massive problem, based on that.  I'm not sure whether that's the correct place to insert a stage.
[12:47] <wookey> yes. It may be better to build libcap-ng without language bindings, but this'll do for now
[12:49] <wookey> I got rid of a bootstrap-modified package momentarily as nice new pam had updated autofoo, but then it broke with audit :-(
[12:49] <caribou> pitti: just read your reply to my email about apport mods for kdump-tools
[12:50] <caribou> pitti: looks like I may have mixed up the order. Which solution do you think would be better to implement ?
[12:50] <caribou> pitti: have the upstart script traverse the /var/crash/{timestamp} dirs or /usr/share/apport/kernel_crashdump ?
[12:51] <pitti> /usr/share/apport/kernel_crashdump does all the processing you want, but that's just my gut feeling
[12:51] <pitti> caribou: I don't have a strong opinion either way, but smearing out the logic over many doesn't seem to make things easier
[12:51] <pitti> caribou: bbl, lunch
[12:51] <caribou> pitti: sure, ttyl
[13:01] <dupondje> pitti: any chance to check https://bugs.freedesktop.org/show_bug.cgi?id=53029 ? :)
[14:49] <pitti> dupondje: re (meeting)
[14:50] <pitti> dupondje: I'm afraid this bug doesn't tell me anything -- it speaks about LibreOffice, cups authentication, and is against ConsoleKit !?
[14:53] <jcastro> Now that cd size doesn't really kill us anymore can we put real vim on the default install again?
[15:00] <cjwatson> jcastro: can't say I'd object, certainly ...
[15:00]  * cjwatson ← hugely biased
[15:01] <jcastro> yeah me too, I mean, it's some kind of law, we have to have vi, and the one in there isn't very good.
[15:02] <jcastro> I am wondering if it's worth bringing up seriously, or if it's too geeky
[15:06] <dupondje> pitti: well didn't create that bug :) The issue is that when printing in LibreOffice to a network printer (samba), it doesn't ask a password
[15:06] <dupondje> so the print job cannot be sent to the network printer
[15:07] <dupondje> if you print in gedit for example, it just gives a popup for credentials
[15:07]  * xnox would like to change nano to have -E option enabled by default
[15:08] <xnox> jcastro: only if we add zile as well
[15:08] <tjaalton> xnox: that would be bad for makefiles :)
[15:08] <xnox> tjaalton: but it's totally bad for python files
[15:09] <pitti> dupondje: I reassigned it to LibO
[15:09]  * xnox ponders to wrap a file call around nano to set -E for python.
[15:10] <dupondje> pitti: thx, I guess its libreoffice gui that should ask for a passs?
[15:10] <pitti> dupondje: they have their own dialogs, yes; they don't use the GTK ones
[15:11] <dupondje> k :) cause not being able to print in a office package is quite a blocker imo :P
[15:12] <pitti> well, it's one rare use case
[15:13] <pitti> it doesn't seem to me that a lot of office workers woudl be required to supply a password every time they print
[15:13] <dupondje> password protected print share isn't that weird
[15:13] <dupondje> anyway :) should get fixed
[15:17] <cjwatson> actually that's the wrong way round isn't it
[15:17] <ogra_> whats wrong with his connection ?
[15:18]  * ogra_ doesnt see crazy join/part messages or so
[15:18] <ev> woo, thanks cjohnston
[15:18] <ev> cjwatson:
[15:18] <cjwatson> it was broken some days ago but Fuchs removed the ban last night
[15:18] <ogra_> oh
[15:18]  * ogra_ sees the other channel
[15:18] <cjwatson> 00:08 -!- mode/#ubuntu-devel [-b *!*@ubuntu/member/evand$##fix_your_connection] by Fuchs
[15:18] <ogra_> yep
[15:18] <cjwatson> So I didn't actually do anything other than accidentally restore it briefly :)
[15:19]  * ogra_ found the answer in #ubuntu-context :)
[15:19] <ogra_> (also called -release)
[15:42] <hallyn> all right so when you boot without 'quiet splash', after the boot text has scrolled by, the text font changes right before x starts..  is that the console-setup-tty done the udev rule (85-kbd-cofig)?
[15:42] <hallyn> or the actual loading of fb module?
[15:45] <ogra_> there are two console-setup runs ... one is from the udev rule the other from an upstart job
[15:45] <ogra_> (both do the same afaik)
[15:46] <ogra_> and if you set FRAMEBUFFER in your initrd config you can enable a third one in the initrd
[15:46] <ogra_> (or if you use break=)
[15:46] <hallyn> right i've commented out the one from upstart
[15:46] <hallyn> (locks up right after that)
[15:46] <ogra_> then it should be the udev rule
[15:47] <hallyn> ok thanks
[16:04] <slangasek> wookey, cjwatson: I've actually already had to re-disable libaudit in Debian because unstable is still using libaudit0 which isn't multiarched; so if you guys think this is a problem for bootstrapping we can back it out in Ubuntu too for now.  Though in any case, stage patches welcome
[16:20] <pitti> so, I keep getting "Connection was refused by other side: 111: Connection refused." with current juju in raring and CanoniStack/EC2; that did work until some weeks ago; is anyone else using this?
[16:22] <pitti> (both for bootstrap and for status)
[16:23] <hrw> btw - does someone know some xmodmap/xkb editor which can be used by person lacking any knowledge of x11 internals?
[16:23] <cjwatson> slangasek: I feel stagifying pam for this would be the wrong answer; best to do the staging further down, I think in libcap-ng in this case
[16:23] <pitti> I used xev to determine keycodes, and then just write reasignments into ~/.xmodmaprc
[16:23] <pitti> hrw: ^
[16:25] <hrw> pitti: chromebook is nice laptop for travelling but lack of pgup/dn and delete keys makes some things complicated
[16:26] <pitti> hrw: my ~/.xmodmaprc swaps Escape and Caps Lock
[16:26] <pitti> I need Esc all the time (vim), but never ever Caps Lock
[16:27] <hrw> I usually have Ctrl on CapsLock
[16:27] <hrw> \
[16:27] <hrw> Chromebook has Meta instead of CapsLock
[16:38] <wookey> slangasek: I've done a stage patch. Will file shortly
[16:40] <slangasek> wookey: thanks
[16:45] <wookey> filed https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1126404
[16:51] <cjwatson> Ah, I hadn't realised audit needed explicit porting to new architectures
[16:51] <cjwatson> Fair enough then
[16:52] <scientes> also the audit defines for arm is in <elf.h> but <audit.h> for x86
[16:52] <scientes> * <linux/audit.h> i believe
[16:52] <scientes> AUDIT_ARCH_ARM
[17:13] <bigon> wookey: are you planning to proposed that patch for pam to debian too?
[17:15] <cjwatson> bigon: "16:04 <slangasek> wookey, cjwatson: I've actually already had to re-disable libaudit in Debian [...]"
[17:15] <stokachu> in the installer i see things such as debconf: --> GET netcfg/get_ipaddress followed by debconf: --> INPUT critical netcfg/bad_ipaddress
[17:15] <stokachu> but im not sure where in the code for the installer this is located
[17:15] <cjwatson> stokachu: apt-get source netcfg
[17:15] <bigon> cjwatson: ah well, thanks
[17:16] <stokachu> ah there we go
[17:16] <cjwatson> and that's due to preseeding static networking without preseeding all the necessary things that go with it
[17:16] <cjwatson> wouldn't happen interactively - you'd be asked for the IP address
[17:17] <stokachu> i think from the logs it stated it was using ubuntu-server preseed file
[17:17] <stokachu> lemme double check
[17:17] <cjwatson> Certainly not the stock one on server CD images
[17:17] <stokachu> Command line: file=/cdrom/preseed/ubuntu-server.seed vga=788 initrd=/install/initrd.gz DEBCONF_DEBUG=developer
[17:17] <stokachu> thats not one we provide?
[17:17] <cjwatson> We do, but I bet that's been modified by somebody somehow
[17:17] <cjwatson> Because our default preseeding does not use static networking
[17:18] <cjwatson> It should be possible to see what that file contains a bit earlier in the log, when file-preseed runs
[17:18] <stokachu> the OP stated that in debug mode it will ask the user for static ip
[17:19] <cjwatson> Somebody's probably preseeded netcfg/use_autoconfig=false, or interactively answered an equivalent question
[17:19] <stokachu> and without it is when the malformed IP address error is shown during interactive mode
[17:19] <stokachu> ok
[17:19] <cjwatson> If you show me the whole bug and syslog I can look
[17:22] <cjwatson> ah, right, it's fallen back to static networking because DHCP failed, I guess
[17:23] <stokachu> yea it looks like the link isn't ready in time
[17:23] <stokachu> cjwatson: i pm'ed you the case
[17:24] <stokachu> the link seems to become available and it looks like we try to get the ipaddress from that
[17:24] <stokachu> and thats where the failure occurs with the malformed ip
[17:25] <cjwatson> Don't agree :)
[17:25] <cjwatson> I'm following up to the bug
[17:26] <cjwatson> But the IP address error is a red herring
[17:26] <wookey> bigon: pretty much everything I've filed in last month needs to go to debian too
[17:26] <wookey> but I've not got round to making corresponding patches for whatever the debian version is
[17:29] <cjwatson> stokachu: followed up
[17:29] <stokachu> cjwatson: interesting, do you think b/c dhcp took longer than someone was willing to wait they cancelled it
[17:29] <stokachu> ?
[17:30] <cjwatson> stokachu: look at the timestamps though
[17:30] <stokachu> ah yea
[17:30] <cjwatson> If they did cancel it deliberately they were bloody quick off the mark
[17:30] <stokachu> someone had a trigger finger
[17:31] <cjwatson> Which is why I was wondering if somebody might have left a book on the F12 key :)
[17:31] <cjwatson> Or something along those lines
[17:31] <stokachu> hah ok ill see if they can run some more tests
[17:31] <stokachu> cjwatson: thanks :)
[17:32] <cjwatson> Actually, following up again
[17:34] <doko> what was the replacement for jockey in quantal?
[17:35] <cjwatson> ubuntu-drivers
[17:35] <cjwatson> -common
[17:41]  * ogra_ wtaches doko tunring into a gamer 
[17:41] <ogra_> :)
[17:41] <Sarvatt> doko: last tab in software sources if you're asking where the gui is (yeah that makes no sense to me either)
[17:42] <ogra_> it didnt make much sense where it was before either ...
[17:42] <ogra_> when we had it pop up and show a notification icon, that made sense ...
[17:42] <ogra_> but that is gone
[17:55] <cjwatson> stokachu: demonstration: boot a server image in kvm and hold down enter.  you'll see exactly the same effect.
[17:55] <stokachu> ah interesting
[17:56] <stokachu> yea from the SS itlooks like they are using some virtual console through ilo to do the installation
[18:06] <slangasek> hallyn: have you seen anything like bug #1126488, by chance?
[18:08] <hallyn> slangasek: no, not that i've noticed
[18:08] <hallyn> zul: ^ ?
[18:08] <slangasek> ok
[18:08] <sarnold> slangasek: does this look like it? https://bugzilla.redhat.com/show_bug.cgi?id=894486
[18:08] <hallyn> (but for most vms that i end up hitting the net with, i don't use libvirt)
[18:08] <zul> hallyn: nope
[18:10] <sarnold> slangasek: 2.66test13 has a fix for the fix for the fix.... see if https://launchpad.net/~mdeslaur/+archive/testing dnsmasq fixes your issue?
[18:10] <slangasek> sarnold: thanks, I'll give it a try later today
[18:58] <slangasek> xnox: do you know the status of bug #1095117?  You had it marked 'in progress', someone else marked it 'fix released', I've just seen the crash here
[18:58] <slangasek> sarnold: looks like mdeslaur's package fixes the dnsmasq issue
[18:59] <xnox> slangasek: i know the fix went into lp:software-center. I did request for it to be released into raring + stable releases.
[18:59] <slangasek> ok
[18:59] <xnox> I don't know if it has or not.
[19:00] <slangasek> xnox: I've reopened the bug; it's still assigned to you, dunno if that's correct
[19:00] <xnox> we have an software-center uploader now
[19:00] <xnox> maybe i should just cherry pick....
[19:01] <xnox> dobey: can you cherry-pick bug 1095117 into raring/quantal/precise (i think it applies to all three)?!
[19:07] <dobey> xnox: well, i plan to do a software-center release as soon as i can. i don't know when i'd be able to get the quantal/precise SRUs done though
[19:07] <xnox> dobey: that bug is high on errors
[19:07] <dobey> my cup, it overfloweth with things i need to do
[19:07] <xnox> =/
[19:07]  * xnox notes down to buy a bigger cup for dobey
[19:07] <xnox> no worries =)
[19:08] <dobey> xnox: ok, there are a few others too. and the switch to python-oauthlib has created a few critical issues;
[19:08] <xnox> dobey: will you be able to pick things up if I cherry pick and upload stuff and not loose it in subsequent uploads?
[19:08] <dobey> switch in u1
[19:08] <xnox>  /o\
[19:08] <dobey> xnox: i don't know what you mean by cherry pick exactly. software-center is a native package (and a pain)
[19:09] <dobey> xnox: if you want to propose branches against the older series, i can review them though, and you can make releases into {precise,quantal}-proposed from the appropriate series branches i suppose
[19:10] <xnox> dobey: oh is that how you manage it, sounds good.
[19:10] <xnox> dobey: which branches are used for what?
[19:11] <xnox> well 5.2 and 5.4 easy =)
[19:11] <dobey> xnox: no. i only started dealing with software-center recently. so mostly nothing is how i would generally manage things at the moment :)
[19:12] <dobey> but that will change soon
[19:12] <xnox> i'll follow current state of affairs and i hope that won't break things much for the future
[19:12] <xnox> dobey: will it be autolanding?
[19:12] <dobey> xnox: only trunk is managed by tarmac at the moment
[19:13] <dobey> i haven't had time to deal with getting all the older branches converted to it
[19:14] <dobey> xnox: but just go ahead and include the changes to debian/changelog in your branches for the older series as well, and i'll review/merge them, and then you can do the releases into -proposed for them
[19:14] <xnox> ack.
[19:15] <doko> jamespage, do you mind having bnd (and deps) in main?
[19:15] <doko> to generate osgi files
[19:22] <doko> bdrung, well, you added apparently hardening flags for these lo b-d's but did forget to add verbose build logs ... so how to validate from the build log?
[20:10] <cjohnston> slangasek: ping
[20:11] <slangasek> cjohnston: heya
[20:17] <doko> bdrung, I had to look at the debdiff to understand "Fix hardening-no-fortify-functions lintian warning."
[20:32] <cjohnston> slangasek: sorry. on shift and got a call right after i pinged you. iirc you were working on a fix in lp as far as blueprints being exported
[20:34] <slangasek> cjohnston: well, once upon a time I was; IIRC though, Curtis nacked that branch
[20:34] <cjohnston> slangasek: Do you remember the reason?
[20:34] <slangasek> let me see if I can find it in LP
[20:35] <slangasek> https://code.launchpad.net/~vorlon/launchpad/lp.994110/+merge/105078
[20:36] <cjohnston> slangasek: i haven't made it back yet, and am still on my cell so i can't open the link right now
[20:36] <slangasek> cjohnston: I frankly didn't understand that response, so I haven't followed up
[20:37] <cjohnston> ok. ill look when i get back. it's something I'm very interested in right now.
[20:37] <slangasek> '"We should only need to target the blueprint to the sprint to get it into the scheduler" is the insight needed to do the proper fix. Re-targeting is not updating the SpecificationDefinitionStatus for the drivers and workers to make it clear the definitionneeds to be realigned with the rest of the work for the series.'
[20:37] <slangasek> I guess he means that this should be fixed deeper in LP, such that when you retarget a blueprint, the definition status is automatically changed
[20:38] <slangasek> however, sprint != series
[20:38] <slangasek> so I'm not sure I agree with that
[20:38] <cjohnston> hrm. ok.
[20:40] <cjohnston> thanks slangasek
[20:55] <cjohnston> slangasek: fwiw, I read what he wrote as that the definition shouldn't be relevant to the blueprint being exported.. The blueprint should be exported if the blueprint is proposed for a sprint AND accepted for a sprint, regardless of what the definition is.. So removing the logic for the definition effecting what appears on the list
[20:56] <slangasek> cjohnston: well, except that was what my branch implemented and he rejected it? :)
[20:58] <cjohnston> He didn't reject it, he put a comment on it.. I am unable to tell from his comment if he is in favor of the change or not.
[20:59] <cjohnston> nm. I stand corrected
[20:59] <cjohnston> missed that
[22:52] <doko> kirkland, https://launchpad.net/ubuntu/+source/ssh-import-id/3.12-0ubuntu1/+build/4304611
[22:52] <kirkland> doko: hi
[22:52]  * kirkland looking
[22:53] <kirkland> doko: thanks
[23:01] <kirkland> doko: why didn't I get a build-failure message?
[23:03] <doko> kirkland, I don't know
[23:09] <YokoZar1> slangasek: a fresh install of raring64 seems to reproduce the unable to install wine1.4:i386 without any additional futzing, not sure why it wasn't working in a chroot for you (maybe no ubuntu-desktop?)
[23:10] <slangasek> YokoZar1: it was a chroot, definitely no ubuntu-desktop installed
[23:10] <YokoZar1> slangasek: Yeah so the conflict is probably with some default but not essential package
[23:17] <mlankhorst> YokoZar1: could you upload wine?
[23:21] <YokoZar1> mlankhorst: new wine1.5 to PPA?  If it doesn't require any changes to the patches, sure.
[23:21] <mlankhorst> afaict probably not
[23:21] <YokoZar1> mlankhorst: kk
[23:21] <mlankhorst> thanks