[00:00] <kees> upstream has stated that debugfs "should not be used on production systems".
[00:00] <kees> there are things being used, though, so we should move towards getting rid of it.
[00:00] <Keybuk> no, upstream has stated that it should be used on production systems
[00:00] <kees> they have said both things.
[00:00] <Keybuk> http://article.gmane.org/gmane.linux.kernel/1104038
[00:01] <kees> what they said was "it should not be used on production systems, except for ftrace, which should move out of debugfs"
[00:01] <kees> I asked what the "good reasons" where, and it boiled down only to ftrace
[00:02] <Keybuk> well, ftrace and that usb/devices file
[00:02] <kees> both should move :)
[00:02] <Keybuk> ftrace is the hugely important interface I'm worried about
[00:02] <kees> ftrace is root-only, so, again, it doesn't matter
[00:02] <Keybuk> things like blktrace too
[00:02] <kees> as root :)

[00:03] <kees> anyway, I was convinced to not _remove_ the mount. ;)
[00:03] <Keybuk> if only ubuntu didn't let users login as root ;-)
[00:03] <Keybuk> kees: were you? your change to mountall suggests you want to remove it still
[00:04] <kees> I do still want to remove it; but due to ftrace and drm debugging, I left it, available to root only, for now.
[00:05] <Keybuk> you realise that the buggy things will just end up back in /proc and /sys again?
[00:06] <Keybuk> or we'll end up with a thousand kernel filesystems again
[00:08] <kees> Keybuk: debugfs remains a dumping ground. at least there are rules for /proc and /sys
[00:09] <kees> Keybuk: if it was totally a theoretical danger, I would have left it as it was. but now with multiple privilege escalation vulnerabilities coming out of there, I want nothing to do with that filesystem. it is dangerous in the general case.
[00:09] <Keybuk> there were just as many bugs in /sys with files that were world-writable, no?
[00:09] <kees> none that were so drastically horrible, though
[00:09] <Keybuk> what was the drastically horrible case in debugfs?
[00:10] <kees> http://jon.oberheide.org/files/american-sign-language.c
[00:11] <Keybuk> that's exactly the kind of interface that will simply get moved to /sys though
[00:11] <Keybuk> with probably the same bugs it has in debugfs
[00:12] <kees> well, /sys has rules, and debugfs doesn't, so I suspect people will think twice before putting crap into /sys
[00:14]  * Keybuk hands you a F in history
[00:15] <Keybuk> debugfs was created because people *were* putting crap into /sys without thinking
[00:15] <kees> right, and now they can continue doing that without endangering people since it'll be root-only
[00:15] <Keybuk> on Ubuntu only ;-)
[00:15] <Keybuk> so are you going to manually check all incoming software
[00:16] <Keybuk> including things like vmware? :p
[00:16] <kees> I already produced a list of all the supported software (in main) that uses debugfs.
[00:16] <kees> if you have have special case, adjust the mounted-debugfs.conf file.
[00:17] <Keybuk> well, vmware was the one I was thinking of
[00:17] <Keybuk> I don't know how they use it this week
[00:17] <Keybuk> it took them long enough to stop using the older interfaces and update to that
[00:17] <Keybuk> but then you probably don't care on the basis that vmware's kernel modules are probably buggy
[00:17] <kees> people should be using kvm.
[00:17] <lifeless> s/probably//
[00:17] <kees> also that
[00:18] <Keybuk> kees: hehe, the first stumbling block is that the kvm ubuntu documentation appears to have been raped by the server team
[00:18] <Keybuk> "you don't want this, you want lib-ubuntu-virt-builder!"
[02:47] <cnd> Riddell, still around?
[02:47] <cnd> the qt package ftbfs for arm
[02:48] <maco> cnd: it's 3am for him
[02:48] <cnd> ahh
[02:48] <cnd> maco, thanks
[02:48] <cnd> I'll send him an email then
[06:25] <blahsphemer> I'd like to discuss a gsoc project. Is anyone available?
[07:38] <lamont> ScottK: nice
[07:55] <didrocks> good morning
[08:01] <pitti> Good morning
[08:13]  * pitti fixes python-aptdaemon-gtk component to fix CD builds
[08:42] <Daviey> persia, I noticed you assigned yourself bug #231060... How are you getting on, and do you think it's a bug we can target for a natty milestone?
[11:03] <pitti> ev: is the pygi port of usb-creator going to make it? or should we just postpone that to o?
[11:06] <ev> pitti: going to have to postpone.  I got caught up in the installer partitioner redesign in the end.
[11:07] <pitti> ev: ack
[11:10] <mok0_> I need a recommendation for  a good XML library for C (C++)? It doesn't matter if it's SAX or DOM, it just needs to be easy to use. I just need it to parse a rather small data file
[11:12] <ev> expat?
[11:13] <mok0_> ev:  I've looked at expat, but it's not exactly easy to use :-)
[11:13] <ev> ah, fair enough
[11:13] <mok0_> ev: I was hoping for "Everyone uses ... and it's great" :-)
[11:15] <ev> have you tried libxml2?
[11:15] <ev> I don't recall it being particularly difficult to use
[12:34] <GunnarHj> ScottK: Hi Scott, can we talk about bug 719815?
[13:17] <GunnarHj> dpm: Hi David, are you there?
[13:17] <dpm> hey GunnarHj
[13:18] <GunnarHj> dpm: Wondering about bug 710151 - guess that somebody ought to fix it before Natty is released.
[13:18] <GunnarHj> dpm: It's apparently /usr/share/language-selector/data/pkg_depends that needs to be altered. Do you know which changes are required exactly?
[13:19] <dpm> GunnarHj, no, sorry, I don't know, perhaps pitti or someone else with more packaging knowledge can answer best? ^^
[13:20] <pitti> right, that needs to be update
[13:20] <pitti> d
[13:20] <pitti> but I'm not sure what will happen with all the -hyphenation and -thesaurus packages, as they haven't been renamed yet
[13:23] <pitti> dpm, GunnarHj: (asking Sweetshark in #u-desktop)
[13:24] <dpm> thanks pitti
[13:24] <GunnarHj> dpm, pitti: Tried to reach doko_ yesterday, since he is a member of the LibreOffice Packaging team (didn't succeed).
[13:24] <GunnarHj> dpm, pitti: switching to #ubuntu-desktop
[13:26] <dpm> GunnarHj, Sweetshark is the new office stack maintainer
[13:27] <GunnarHj> dpm: Aha, didn't know. Thanks!
[13:28] <beuno> ev, ping. I've been trying to do a fresh install of natty on my maverick since the 21st, but I can't get neither the alternate nor the live-cd to install. Are there any known bugs?
[13:35] <pitti> tseliot: hey, how are you?
[13:35] <tseliot> hi pitti, I'm fine, thanks, you?
[13:45] <fta> mvo, hi, http://paste.ubuntu.com/572181/  known?
[13:54] <mvo> fta: no, could you run in --debug --dry-run mode?
[13:54] <mvo> fta: and mail me the deb where it fails?
[13:59] <fta> mvo, brltty: http://paste.ubuntu.com/572183/
[14:01] <mvo> fta: thanks, could you plesase file a bug? I think its some stupid static buffer being too small
[14:01]  * mvo has some vague memory about this particular code path
[14:04] <ev> beuno: amd64?
[14:04] <beuno> ev, nope, i386. I tried running ubiquity in debug mode, and there isn't anything intersting in the logs either
[14:04] <ev> beuno: is it crashing or hanging?
[14:04] <beuno> the alternate cd (installing from pendrive) says it can't find the cd
[14:04] <beuno> ev, hanging
[14:05] <beuno> and the live cd hangs after the screen that checks for power, internet, etc
[14:05] <ev> oohhh, perhaps it's the bug in partman-auto
[14:05] <beuno> just the installer hangs
[14:05] <ev> do you have unpartitioned space on one of your disks?
[14:05] <chrisccoulson> huh? http://launchpadlibrarian.net/65125588/buildlog_ubuntu-natty-amd64.firefox_4.0~b12%2Bbuild1%2Bnobinonly-0ubuntu2_CHROOTWAIT.txt.gz
[14:05] <beuno> ev, ah, probably, yes. I nuked the partitions at some point trying to get things moving forward
[14:06] <beuno> the last I can see in debug logs are about partitions
[14:06] <chrisccoulson> ^^ lamont - any idea what happened there?
[14:07] <ev> beuno: yeah, entirely my fault (bug 722198).  The next daily{,-live} CD should have the fix.
[14:07] <lamont> chrisccoulson: I don't suppos you want to give me the (acutally useful for looking at things) URL for the build record???
[14:08] <chrisccoulson> lamont, https://launchpad.net/ubuntu/+source/firefox/4.0~b12+build1+nobinonly-0ubuntu2/+buildjob/2286209
[14:10] <fta> mvo, bug 724994
[14:11] <lamont> chrisccoulson: uh.. yeah, I have an idea, and I'm going to go cry for a bit in a little while.  meantime, I'll get it fixed.  thanks
[14:11] <chrisccoulson> lamont, excellent, thanks :)
[14:12] <ev> beuno: if you'd rather not wait, hit Try Ubuntu on the live CD, then patch this in and run the installer again: http://paste.ubuntu.com/572185/
[14:13] <beuno> ev, I'll give that a try, at least to help confirm it. I'm also up for doing anything that will help debug further or whatever
[14:13] <ev> thanks, let me know if that doesn't do the trick then
[14:13]  * beuno tests
[14:21] <mvo> fta: I commented in the bug, a tiny test app seems to work for me
[14:21] <beuno> ev, still seems to hang for me, in the debug log the last I see is:  <-- GET partman-auto/disk, followed by: --> 1
[14:22] <beuno> (compiz crashed, but I don't think that would change anything)
[14:23] <ev> beuno: can you stick a set -x towards the top of /lib/partman/automatically_partition/15reuse/choices and pastebin /var/log/syslog after another run through?  You might want to check to make sure the parted_server process isn't running before you start ubiquity.
[14:24] <beuno> ev, sure
[14:24] <ev> thanks
[14:40] <cnd> Riddell, hey, just saw your email
[14:40] <cnd> ARM has doubles
[14:40] <cnd> otherwise X wouldn't work at all
[14:40] <cnd> the issue is only that qt's qreal is typedef'd as a float on ARM
[14:40] <cnd> so the size of qreal != size of double on ARM
[14:41] <cnd> if you typecast as you wrote in the email, it will actually runtime break
[14:42] <Riddell> cnd: but if you use a double there then further uses which expect a qreal will break no?
[14:42] <Riddell> e.g. qreal value = (*values++ - tdi.xivPosX.min) / (tdi.xivPosX.max - tdi.xivPosX.min)
[14:42] <cnd> Riddell, in that line, *values will be a double
[14:42] <cnd> and the end result will be a double casted into the float qreal
[14:43] <cnd> the conversion will happen automatically at assignment time
[14:43] <cnd> however, if you typecast values to qreal *(i.e. float *)
[14:43] <cnd> then values++ will advance the pointer by 4 bytes instead of 8
[14:44] <beuno> ev, here's the closest I can do to pastebin: http://plixi.com/p/79872527
[14:45] <ari-tczew> tseliot: beer for new nvidia drivers!
[14:45] <tseliot> :)
[14:51] <Riddell> cnd: ok you convinced me
[14:52] <cnd> Riddell, I'm crossing my fingers too
[14:52] <cnd> I wish I had an arm machine to test :)
[14:52] <cnd> we can probably ask a mobile team dev to test it out
[14:52] <cnd> to make sure
[14:52] <ev> beuno: does `sudo parted_devices` work or does it output an error?
[14:53] <Riddell> cnd: how would you test?
[14:53] <cnd> Riddell, the easiest would probably be to connect an apple magic trackpad
[14:53] <cnd> and then run one of the qt touch examples
[14:54] <cnd> though, some of the arm dev kits now have multitouch screens I believe
[14:54] <cnd> so they should work too
[14:54] <cnd> barry! just the person I need :)
[14:55] <cnd> (sorry to pounce :)
[14:58] <janimo> cnd, there is an arm machine in the data center, kakadu.canonical.com if you want to test things. You may need an account from IS
[14:59] <cnd> janimo, I'd need someone's finger too :)
[14:59] <cnd> Riddell, actually, now that I think of it
[14:59] <janimo> ah you mean test beyonf simply building it
[14:59] <cnd> I can emulate a touch device
[14:59] <cnd> so if I could get remote access to an ARM machine I could test it
[15:00] <Riddell> cnd: ScottK can probably give you access
[15:00] <cnd> Riddell, ok, are we going to test before we push?
[15:00] <cnd> or vice versa?
[15:00] <cnd> I'm pretty confident it will work as I described
[15:01] <cnd> it's just to verify really
[15:01] <Riddell> cnd: well that involves building which takes days, I think we should just upload then test once it's in the archive
[15:01] <cnd> Riddell, sounds good
[15:01] <cnd> it won't break anything other than the qt touch examples
[15:01] <cnd> which won't work anyways without the patch :)
[15:06] <janimo> cnd, I think having it build is a good first step
[15:06] <janimo> if it has bug later the arm team will help look into them
[15:06] <cnd> janimo, ok, thanks!
[15:07] <janimo> it's not as if it is a regression so noone will be roveolted if it does not work perfectly
[15:09] <doko__> smoser: about bug #634487: "Any other tasks can be closed as 'invalid' or anything" ?
[15:10] <smoser> doko, well, it is clearly a kernel bug.
[15:10] <doko> ok
[15:10] <smoser> so, you could make the java tasks invalid. the only reason i didnt' do that was because that seems like it might reduce the find-ability
[15:10] <smoser> you have thoughts on that ?
[15:11] <doko> mvo: ^^^
[15:12] <smoser> i say clearly a kernel bug because obviously no user space process should be able to wreak such havoc
[15:12] <beuno> ev, it works, it outputs the hd and the usb drive
[15:14] <ev> beuno: I don't suppose there are any exceptions in /var/log/partman.log?
[15:14]  * beuno looks
[15:14] <doko> smoser: thanks!
[15:15] <beuno> ev, nope, it looks pretty normal
[15:15] <ev> rubbish :-/
[15:16] <ev> beuno: can you rsync/usb disk the logs off of there and attach them to a new bug report?
[15:16] <ev>  /var/log/installer/debug, /var/log/syslog, and /var/log/partman
[15:17] <beuno> ev, sure, I'll do it now
[15:17] <ev> thanks
[15:17] <smoser> mvo, can you mark the linux-ec2 task as invalid on natty and maverick please ? for some reason it doesn't do anything when i do it.
[15:18] <tgall_foo> doko,   I'm working on a very minimal system image for arm systems, from dpkg -r --no-act it would appear that for python the only dep is lsb-release    and python-minimal just reports that it's an essential pkg but nothing deps on it .. does that sound right ?
[15:18] <fta> mvo, commented back
[15:18] <ari-tczew> pitti: you might be interested in looking on bug 721399
[15:20] <pitti> ari-tczew: I already fixed that in upstream git and in Debian, it's pending upload; I'll update the bug
[15:20] <mvo> smoser: trying it now, LP is not in a good mood today
[15:20] <ari-tczew> pitti: ok thanks
[15:21] <doko> tgall_foo: sorry, asac can't do without bitching
[15:21] <mvo> smoser: sorry, I keep getting oopses, timeouts now
[15:21] <doko> tgall_foo: for that you'll have to rewrite lsb_release in something else than python
[15:22] <tgall_foo> doko, understandable
[15:22] <ari-tczew> pitti: did you use BlackZ's patch?
[15:22] <tgall_foo> doko, in the grand scheme for a minimal system is lsb-release really necessary ?
[15:22] <beuno> ev, hm, I didn't create storage space on the usb installer and it's not mounting other usb drives (and also, no network!). I'll have to re-create the installer with some storage and go through it again. Will take a bit longer  :)
[15:22] <pitti> ari-tczew: no, I fixed it 4 days before already
[15:22] <pitti> ari-tczew: http://cgit.freedesktop.org/hal/commit/?id=8f624253f0135ca77a893ad4e8168f51ef90d4da
[15:22] <ari-tczew> pitti: okok
[15:22] <asac> doko: thanks!
[15:22] <asac> :-P
[15:22] <ari-tczew> pitti: nice
[15:22] <ev> beuno: okay
[15:23]  * pitti uploads a debian svn snapshot then to get this off the radar
[15:23] <doko> tgall_foo: I don't know which scripts depend on it, maybe just search for lsb_release?
[15:24] <tgall_foo> doko, ok thanks!
[15:25] <mvo> thanks for the update fta!
[15:29] <ari-tczew> doko: how do you checking which library is missing? e.g. undefined reference to 'fs_element_added_notifier_add'
[15:30] <doko> ari fgrep -r 'fs_element_added_notifier_add' /usr/include, and then dpkg -S ?
[15:31] <soreau> I downloaded a maverick love image a couple days ago but when I try to install it, after clicking the forward button the installer just sits there with busy cursor. Is this expected behavior?
[15:31] <soreau> er..
[15:31] <fta> ari-tczew, or google :) http://farsight.freedesktop.org/apidoc/farsight2/FsElementAddedNotifier.html
[15:31] <soreau> I downloaded a natty live image a couple days ago but when I try to install it, after clicking the forward button the installer just sits there with busy cursor. Is this expected behavior?
[15:32] <ari-tczew> fta: google failed :9
[15:32] <ari-tczew> :(
[15:32] <fta> really? wfm
[15:40] <ev> soreau: yes - the desktop CDs have a bug whereby the installer hangs when there's unpartitioned space on any of the disks.
[15:40] <ev> Fixed CDs will be generated once the live filesystems can be rebuilt.
[15:42] <soreau> ev: ok thank you. Is there any way to install it without this fix?
[15:43] <ev> soreau: you can try patching this in after quitting the installer and killing parted_server: http://paste.ubuntu.com/572185/
[15:45] <soreau> ev: thanks again
[15:45] <ev> sure thing
[16:05] <lamont> chrisccoulson: given back
[16:05] <chrisccoulson> lamont, excellent, thanks!
[16:05] <lamont> that is, I gave back all the afflicted natty/amd64 packages
[16:07]  * pitti scratches his head about the weird hal FTBFS on the buildds
[16:13] <pitti> lamont: would you know any buildd specific issue which could cause a failure like
[16:13] <pitti> chmod -x /build/buildd/hal-0.5.14/debian/tmp//usr/lib/hal/scripts/hal-functions
[16:13] <pitti> chmod: /build/buildd/hal-0.5.14/debian/tmp//usr/lib/hal/scripts/hal-functions: new permissions are rw-r-xr-x, not rw-r--r--
[16:13] <pitti> make: *** [install/hal] Error 1
[16:14] <lamont> nice.
[16:14] <lamont> whcih build is that?
[16:14] <pitti> http://launchpadlibrarian.net/65129778/buildlog_ubuntu-natty-i386.hal_0.5.14-5%2Bsvn1_FAILEDTOBUILD.txt.gz
[16:14] <pitti> (other arches fail as well)
[16:14] <pitti> not locally, though
[16:14] <lamont> ah, cool.  I'm going to let you keep scratching... because I don't understand it at all, unless fakeroot faceplanted
[16:14] <lamont> (the only things I'm interested in right now are build failures on yellow.)
[16:15] <pitti> lamont: this line was added in 2007, nothing that changed recently
[16:15] <pitti> lamont: ok, thanks
[16:15] <pitti> it did build on armel, though
[16:17] <pitti> lamont: another upload just failed with "dpkg-deb: control directory has bad permissions 700 (must be >=0755 and <=0775)"
[16:17] <pitti> why do builds suddenly start failing on permission issues..
[16:30] <lamont> I wonder if something is causing umask issues again...
[16:38] <pitti> Daviey: actually it's eucalyptus b-deps libgwt-user-java; and gwk needs swt-gtk
[16:38] <pitti> chrisccoulson: ^
[16:39] <chrisccoulson> pitti - yeah. there's no runtime dependency either, which is a little suspicious
[16:39] <pitti> so actually there's another alternative to remove swt-gtk from gwt
[16:39] <pitti> chrisccoulson: eucalyptus-java-common binary depends on libgwt-dev-java
[16:40] <chrisccoulson> pitti - libgwt-dev-java doesn't have a runtime dependency on swt-gtk though does it?
[16:40] <pitti> oh, right
[16:45] <Daviey> pitti / chrisccoulson: libgwt-user-java is already heavily modified, and feature restricted to build without a bazillion depends... I suspect it's going to be a world of pain :)
[16:46] <Daviey> Has a bug been raised yet?
[16:46] <pitti> Daviey: by the sound of it, euca could actually need gwt, right?
[16:46] <pitti> Daviey: i. e. do you think it'd be more promising to build euca without gwt, or gwt without swt-gtk?
[16:46] <Daviey> pitti, well the web ui is generated via part of libgwt
[16:46] <pitti> ok, then we should focus on the latter
[16:47] <Daviey> It's Google Web Toolkit btw...not GWT as in Java GWT.
[16:49] <Daviey> pitti, but yes, the later makes more sense IMO... I'm just fearful of how hard it's going to be.  As it was, we didn't suck in a new upstream version of gwt because it seemed like we had to patch out more than 50% of the upstream code to build it.
[16:58] <proti> bug 586786 is really nasty if one wants to use grub with newer kernels.
[16:58] <proti> Oups
[16:58] <proti> bug 586756
[16:59] <proti> It cause the update-grub to ignore every kernel having CONFIG_XEN_PRIVILEGED_GUEST=y for normal boot.
[17:00] <proti> Every kernel since 2.6.37-9 for amd64.
[17:03] <doko> seb128, didrocks, pitti: are any more gnome updates planned? if yes, when (asking for an archive rebuild)
[17:04] <didrocks> doko: for unity/compiz, nothing more until Monday, I think that kenvandine has still some indicators to update
[17:05] <ari-tczew> tseliot: wow, 108MB change file in new nvidia driver!
[17:05] <tseliot> ari-tczew: ??
[17:06] <doko> didrocks: no, I mean at or around an alpha/beta time, and not before Mar 9
[17:06] <ari-tczew> tseliot: diff from 260.19.29-0ubuntu1 to 270.29-0ubuntu1 (108.8 MiB)
[17:06] <ari-tczew> tseliot: looks lige gigantic upgrade ;-)
[17:06] <didrocks> doko: for GNOME itself, we are staying with the 2.32 stack
[17:07] <tseliot> ari-tczew: this diff? http://launchpadlibrarian.net/65129241/nvidia-graphics-drivers_270.29-0ubuntu1_270.29-0ubuntu2.diff.gz
[17:07] <didrocks> so no big changes there
[17:07] <ari-tczew> tseliot: no, one previous
[17:07] <didrocks> doko: then, we have weekly dx update on Thursday (apart in freeze time) for unity, indicators…
[17:07] <tseliot> ari-tczew: aah, the new upstream release, yes
[17:08] <doko> didrocks: and no gnome updates?
[17:08] <didrocks> doko: nothing apart from a . release and cherry-picking some patches from newer version AFAIK
[17:11] <zyga> how can I chroot into something crated with pbuilder-dist
[17:19]  * zyga discovered pbuilder login
[17:37] <ari-tczew> pitti: shouldn't be hal uploaded *5~ubuntu1 or something?
[17:54] <chrisccoulson> lamont, https://launchpad.net/ubuntu/+source/firefox/4.0~b12+build1+nobinonly-0ubuntu2/+buildjob/2286209 failed again :(
[17:54] <chrisccoulson> dpkg-deb: control directory has bad permissions 700 (must be >=0755 and <=0775)
[17:55] <lamont> yeah - I'm guessing something changed in natty today maybe?
[17:55] <lamont> nothing changed on the server that should affect that
[17:56] <chrisccoulson> i'm not too sure. perhaps pitti might know, but i think he's finished for the week
[18:18] <seb128> doko, we will have some updates but they don't plan a new tarball rounds on the serie we are using
[19:26] <kenvandine> chrisccoulson, did you figure out why builds are failing?
[19:26] <chrisccoulson> kenvandine, no, not yet. it started off as amd64, but now the i386 builds are all failing with the same problem too
[19:26] <chrisccoulson> i'm not sure what's changed this afternoon
[19:26] <kenvandine> yeah
[19:26] <chrisccoulson> cjwatson, ^^^
[19:26] <kenvandine> armel is working
[19:26] <chrisccoulson> any ideas?
[19:26] <kenvandine> all of mine are failing too
[19:27] <chrisccoulson> https://launchpad.net/ubuntu/+source/evolution-indicator/0.2.14-0ubuntu3/+buildjob/2286589
[19:27] <chrisccoulson> friday night is not a good time for the world to break :(
[19:28] <micahg> I've had 2 daily updates show archive packages not authenticated today, anyone else seeing this?
[19:28] <kenvandine> i don't think it is something in natty that broke though
[19:28] <kenvandine> pbuilder was still working for me about an hour ago
[19:28] <kenvandine> micahg, i haven't seen that
[19:28] <chrisccoulson> kenvandine, i'm not so sure. lamont thinks it might be, and the way the failure trickled slowly across architectures might suggest that it's a package that recently built
[19:29] <xnox_> micahg, me neither. But it depends which mirror you use and when you caught it with "apt-get update"
[19:29] <chrisccoulson> i guess armel still works because that's slow ;)
[19:29] <kenvandine> my notify-osd upload from this morning failed on both amd64 and i386
[19:29] <micahg> xnox: us.a.u.c
[19:31] <xnox_> micahg, check on lp what is the status for that mirror, how upto date it is for natty. I'm in UK so I get updates slightly quicker ;-) my mirror is a push one from a.u.c
[19:32] <cjwatson> do you have timestamps for when it started breaking on each of amd64 and i386?
[19:32] <cjwatson> even roughly
[19:32] <cjwatson> one problem is that I think lamont is now on a plane, so recovery may be difficult
[19:33] <chrisccoulson> cjwatson, here is the first failure i saw on amd64 - https://launchpad.net/ubuntu/+source/firefox/4.0~b12+build1+nobinonly-0ubuntu2/+buildjob/2286209
[19:33] <chrisccoulson> the i386 build a short time before that worked ok - https://launchpad.net/ubuntu/+source/firefox/4.0~b12+build1+nobinonly-0ubuntu2/+buildjob/2286211
[19:34] <kenvandine> cjwatson, just by looking at commit mail, it looks like the yelp commit was the first to break, and that failed on both i386 and amd64
[19:35] <kenvandine> gbgoffice succeeded on both arches 4 hours ago
[19:36] <kenvandine> yelp failed on both areas 3 hours ago
[19:36] <kenvandine> s/areas/arches
[19:48] <zyga> how can I use custom hooks / archives with pbuilder-dist?
[19:48] <zyga> it will still read .pbuilderc but I'd like to be able to customize this file for each distribution
[20:04] <Sarvatt> nvidia-graphics-drivers failed on amd64 only 5 hours ago https://launchpad.net/ubuntu/natty/+source/nvidia-graphics-drivers/270.29-0ubuntu1
[20:17]  * cjwatson upgrades a natty chroot to see if he can reproduce these build failures
[20:18] <cjwatson> the toolchain upgrades at the start of a successful vs. failed build logs are identical
[20:24] <cjwatson> if somebody could find two successive builds of different versions of the same package on the same architecture, the first of which succeeds and the second of which fails with these permissions errors, that would be very helpful
[20:25] <cjwatson> the previous version of yelp succeeded, but it was over a month ago; something a bit closer would be good
[20:28] <cjwatson> evolution-indicator looks like a good candidate
[20:32] <cjwatson> none of the changed build-dependencies between the failing and succeeding versions of evolution-indicator/i386 are present at all in the failing hal build
[20:32] <cjwatson> so I'm rather tempted to rule out that this is due to a change in natty
[20:33] <psusi> cjwatson: I think you had an opinion the other night on the 'p' partition separator issue for dmraid devices, but I forget what it was.  Did you think it should only be there if the previous character was a digit, and not otherwise?
[20:33] <cjwatson> that sounded reasonable to me but I don't want to force my opinion in this case
[20:33] <kenvandine> cjwatson, yeah, there was 1 line change in the two versions of evolution-indicator
[20:34] <kenvandine> and it builds in pbuilder, realy doesn't feel like natty is broken
[20:34] <psusi> well, I'm trying to figure out if I should work on patching dmraid and parted to drop the 'p' when it is not needed, or not... I got a patch for gparted from upstream to disable its broken handling and rely on libparted to take care of it, so that fixes the bug... propsed for merge and waiting review
[20:34] <cjwatson> though that said that does create an ambiguity - imagine if you're silly enough to create two partitioned devices, one of which is called foo1 and the other of which is called foo1p
[20:34] <cjwatson> yes, I saw your merge request, but I've been head-down on other stuff
[20:34] <psusi> that's the problem gparted had...
[20:35] <cjwatson> it's on the list of stuff the foundations team needs to look at
[20:35] <cjwatson> I don't expect it will be forgotten
[20:35] <psusi> very bad since it can decide that one is not mounted and delete the partition, when the other is mounted
[20:35] <cjwatson> so meh, I don't know, I'd rather people who deal with this stuff more work it out
[20:37] <psusi> I suppose that having the 'p' there when it isn't needed isn't hurting anything for now, after gparted is fixed and we don't use kpartx so it doesn't really matter that it has a different idea
[20:38] <cjwatson> are there any natty builds anyone can find that are still succeeding?
[20:38]  * psusi dives back into the swsusp and plymouth code
[20:40] <cjwatson> cloud-utils worked recently, but I don't think that ships any code that pkg-create-dbgsym would have acted on
[20:40] <cjwatson> ditto nova
[20:40] <james_w> cjwatson, https://launchpad.net/ubuntu/+source/cobbler/2.1.0~bzr2002-0ubuntu1/+buildjob/2286770
[20:41] <james_w> oh
[20:41] <james_w> https://launchpad.net/ubuntu/+builds?build_text=&build_state=built
[20:41] <james_w> xulrunner-2.0 finished 1 hour ago?
[20:41] <james_w> started 3 hours ago
[20:41] <cjwatson> right, I can't find a recent build that used any shared libraries though
[20:42] <cjwatson> that was powerpc - it's not obvious that that's affected yet
[20:43] <ev> debfx: are you planning on uploading that qt4 fix tonight?
[20:45] <james_w> I can't see any recent successful builds on x86 that produced shared libraries
[20:52] <cjwatson> there is misbuilding happening
[20:52] <cjwatson> I'm ringing the IS emergency phone
[20:52] <cjwatson> (successful builds with incorrect permissions on files in .debs)
[20:52] <cjwatson> I recommend developers help by not uploading anything for the time being ;-)
[20:56] <cjwatson> I got through to elmo, but he's not at a computer right now; he's going to try to contact some other folks
[20:56] <hallyn> hm?  do we know what's going on with the builds?
[20:56] <cjwatson> it looks like an incorrect umask
[20:56] <cjwatson> they clearly need to be shut down pending investigation
[20:56] <chrisccoulson> cjwatson, thanks for looking at this btw :)
[20:57] <lifeless> profile defaults could account for this (if a recent chroot rebuild happened). Similarly, sbuild might have gone crazy if we did something silly in LP (but I don't recall anything going past like that)
[20:57] <cjwatson> I'm going to escalate up my management chain and try to find somebody to take over, as it's 9pm on a Friday night and I'd rather like to be elsewhere
[21:01] <cjwatson> (Rick's calling me back in a few minutes)
[21:02] <kenvandine> cjwatson, thx
[21:04] <lifeless> cjwatson: I'm tweeting that there is an issue
[21:05] <lifeless> done - http://identi.ca/launchpadstatus
[21:11] <lamont> chrisccoulson: what all architectures are you seeing this on?
[21:11] <lamont> cjwatson: ??
[21:11] <chrisccoulson> lamont, i386 and amd64 at the moment
[21:11] <chrisccoulson> i haven't seen it on any others, not sure if anybody else did though
[21:11] <cjwatson> what he said
[21:11] <cjwatson> it doesn't seem to be happening on powerpc so far
[21:11] <lifeless> lamont: can you disable all the buildds ?
[21:11] <lifeless> lamont: for those arches at minimum
[21:12] <cjwatson> lamont: I've diffed fail/success build logs and can find no relevant package differences
[21:12] <lamont> ppa and archive? or just archive?
[21:12] <cjwatson> don't know, unfortunately
[21:12] <cjwatson> is there a URL somewhere listing recent PPA builds?
[21:12] <lamont> no
[21:13] <cjwatson> the build failures don't concern me (in an OMG STOP THE WORLD) kind of way, but the misbuilds certainly do
[21:13]  * lamont put the world on manual
[21:14] <cjwatson> is a process' umask visible in /proc/pid?
[21:15] <broder> cjwatson: last time i looked for this, i think i concluded "no"
[21:15] <cjwatson> I'm also failing to find it if it is
[21:15] <broder> i thought i ended up having to gdb the process
[21:16] <lamont> that's what I'm trying to figure out
[21:16] <lamont> 2011-02-25 15:18:00 status installed libc6 2.7-10ubuntu8
[21:17] <cjwatson> in what context?
[21:17] <cjwatson> hm, hardy, I assume the root
[21:18] <lamont> stupid system
[21:18] <cjwatson> lamont: what was the previous version?
[21:18] <lamont> hardy in the root
[21:18] <cjwatson> I don't know exactly, but that's a plausible time for failures to have begun
[21:22] <lamont> bah. that's libc6 triggers
[21:22] <lamont> 2011-02-25 15:18:00 status triggers-pending libc6 2.7-10ubuntu8
[21:22] <lamont> 2011-02-25 15:18:00 trigproc libc6 2.7-10ubuntu8 2.7-10ubuntu8
[21:22] <lamont> 2011-02-25 15:18:00 status half-configured libc6 2.7-10ubuntu8
[21:22] <lamont> 2011-02-25 15:18:00 status installed libc6 2.7-10ubuntu8
[21:22] <lamont> thanks dpkg
[21:22] <lamont> oh.
[21:22] <lamont> so... what changed in sudo between hardy and lucid?
[21:22] <lamont> anything about that environment cleaning that would affect umask?
[21:22] <lamont> wow. c rap internet today
[21:23] <lamont> that actually doesn't look all that promising
[21:25] <lamont> interestingly, sbuild has a umask of 077
[21:29] <kees> barry: I've exhausted the FAQs. can I ask you a python utf-8 question?
[21:29] <barry> kees: sure, but sometimes this stuff hurts my brain (/me is a typical barely monolinguistic american :)
[21:30] <kees> hehe
[21:30] <kees> barry: it seems simple enough to me, but I don't know what I'm doing wrong.
[21:30] <kees> barry: I have text I've read from a file. if I operate on it, python explodes with:
[21:30] <kees> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2531: ordinal not in range(128)
[21:30] <kees> when I try to call something like "strip()" on it
[21:30] <broder> kees: what if you take the string and .decode('utf-8') it?
[21:30] <cjwatson> https://wiki.ubuntu.com/IncidentReports/2011-02-25-Permissions-build-failures
[21:31] <cjwatson> skeleton, please extend
[21:31] <barry> kees: how are you opening the file?
[21:31] <kees> broder: why isn't it utf-8 already?
[21:31] <kees> barry: file(filename).read()
[21:31] <barry> kees: also, we're talking python2 here, right? :)
[21:31] <kees> barry: yeah, natty python
[21:31] <kees> 2.7
[21:32] <barry> kees: that's because you opened the file in binary, so you've got 8-bit data, not text
[21:32] <barry> and probably not 8-bit data containing pure ascii
[21:32] <kees> barry: ah, sorry, no, I used file(filename).readlines()
[21:32] <kees> how do I communicate to python that it should treat this as utf-8?
[21:32] <barry> (aside: built-in file is not the preferred way to open a file, use built-in open)
[21:33] <kees> I thought they were the same?
[21:33] <barry> kees: technically they are, but convention treats `file` as the type and `open` as the function
[21:33] <barry> kees: http://docs.python.org/library/codecs.html
[21:33] <barry> kees: use codecs.open(filename, mode, encoding='utf-8')
[21:33] <barry> then read from that
[21:34] <kees> hunh.
[21:34] <kees> is there a way to have open be that instead?
[21:35] <lamont> cjwatson: in the init-script, I print the umask (=022) and launch the buildd.  gdb on the process shows us at 077 inside the buildd
[21:35] <lamont> post-jaunty, twistd accepts --umask as an option, before that it errors
[21:35]  * cjwatson is handing over to skaet
[21:35] <cjwatson> (who might draft in others)
[21:35] <cjwatson> I'll be back in an hour or two
[21:35] <cjwatson> (but not for long, that will be late for me)
[21:36]  * skaet_ reading through the backscroll
[21:36] <barry> kees: built-in open()?  not without evil and/or upgrading to python3 :)
[21:36] <kees> heh, okay
[21:37] <kees> barry: cool; thanks, that works.
[21:38] <kees> barry: it will be a bit of a pain to fix all the file/open use to use codecs.open, but I'll just grind through it. :)
[21:39] <barry> kees: take comfort that it will at least make your inevitable conversion to py3 easier
[21:39] <barry> :)
[21:40] <ohsix> anyone know offhand why the libasound2 dep in ffb12 was changed?
[21:40] <ohsix> i had it pinned on mav but taking libasound2 with it breaks too many things, i'll have to stick with 11
[21:49] <skaet_> lamont,  do you have any way of assessing which packages have been affected?
[21:50] <lamont> skaet_: we can put together a query (not me, but someone with more db knowledge) of what builds were done today, that at least narrows it down
[21:50] <lamont> fwiw, powerpc and armel are unaffected
[21:50] <lamont> digging into the package list that broke things, but it's confined to hardy
[21:51] <lamont> (for the underlying buildd host os)
[21:56] <skaet_> jdstrand, ^^  can you help with this?
[21:57] <skaet_> lamont, just to be clear,  problem is only natty images built today, or does it stretch beyond?  do we know when the bad builds started?
[21:59] <lifeless> skaet_: can't answer that until we have a cause
[22:00] <lifeless> skaet_: we're discussing it on #launchpad-ops (canonical internal channel) if you want the blow by blow
[22:00] <lamont> skaet_: very unsure at this point
[22:00] <skaet_> lifeless,  thanks
[22:08] <jdstrand> I'm not sure in what way I can help, but I can ask a question
[22:09] <jdstrand> lamont: you said that the underlying hardy os on the buildd is only affecting natty builds?
[22:09] <jdstrand> lamont: did that host get the recent security updates for hardy?
[22:09] <jdstrand> lamont: -security + -updates
[22:25] <lamont> what's a quick build exhibiting this error?
[22:30] <skaet_> james_w ^^ ?
[22:32] <chrisccoulson> lamont, evolution-indicator is pretty quick
[22:52] <ari-tczew> could anyone check this upload? http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/php-mcrypt/natty/revision/14
[22:53] <ari-tczew> I'm wondering whether it's wrong cause there is only new entry in d/changelog.
[22:54] <Laney> it got a new orig
[22:54] <Laney> check the checksums
[23:01] <lamont> skaet_: for completeness, we're working up a list of all the builds that happened during the bad time, failures we can get retried painlessly, the successes are going to be a list to review, I'm afraid
[23:02] <wgrant> lamont: We shouldn't start the build farm until we review failures.
[23:02] <lamont> wgrant: the virtual builders will come back enabled. :(
[23:02] <lamont> though I suppose we could stop the buildd-manager
[23:02] <wgrant> Kill it.
[23:20] <skaet_> lamont, wgrant,  thanks.
[23:22] <lamont> http://pastebin.ubuntu.com/572392/ <-- skaet_ here's your list of suspect builds
[23:22] <lamont> wgrant: status == 2 is fail, correct?
[23:25] <lifeless> lamont: all builds are suspect
[23:25] <lifeless> lamont: even if they succeeded
[23:25] <lifeless> by suspect, I mean probably broken.
[23:26] <wgrant> lamont: 1 == success, 2 = fail
[23:26] <wgrant> I only included those two.
[23:26] <wgrant> depwait and stuff are safe, so aren't in that list.
[23:29] <lamont> lifeless: correct.  hence the list... I'm going to go retry all the failures, but I can't do anything about the successes
[23:29] <lamont> other than generate the list
[23:33] <wgrant> lamont: If you haven't retried them already, don't.
[23:33] <wgrant> We should just do a quick check of potentially problematic successes, if we can.
[23:33] <wgrant> Or we may end up with cascading pain.
[23:33] <wgrant> Most of them seem to be leaves.
[23:33] <wgrant> But not all.
[23:35] <lamont> ok
[23:37] <wgrant> It looks like the primary archive is OK.
[23:40] <cjwatson> nova was a problematic success that I noticed
[23:40] <cjwatson> in the primary archive
[23:40] <cjwatson> that's what made me pull the alarm bell
[23:40] <cjwatson> it was only a few .png files, I think, but I didn't want to spend time assessing
[23:41] <ari-tczew> Laney: so why source hasn't changed?